Date: Tue, 7 Nov 2023 18:45:43 +0000
> he spawned thread could fail to start
> (which is very rare), or the thread might freeze up or fail in some
> way.
In what way? If after std::async is finished "setting up the asynchronous task", the thread it spawns may freeze or fail, what causes that in your use-case? And in what way does your proposed implementation solve that? As always forgive me if I'm mistaken but as far as I can see the only exceptions and failures your suggestion seems to deal with are exclusively related to the call to async, and anything which happens when executing the task is outside the scope of this change.
> If this wait operation times out, or if the value of the future object
> is 0 (corresponding to the 128-Bit UUID
> 00000000-0000-0000-0000-000000000000), then I abandon the future
> object and start again with a new thread and a new future object. I'll
> have a global container of future objects and allow it to get to N
> size before my program tells the user "You need to close the program
> and re-start it".
This sounds a lot like deducing the success or failure of an asynchronous task based some a timer recording it in another thread. Is that not inherently susceptible to race conditions affecting your logic should the scheduler decide to sleep either thread? Indeed is this not a possible cause of your "freezing up or failing in some way"? In any case, I'm not sure that the program design of stacking up enough failed threads/asyncs that the program requires a manual restart to clear itself out is a sufficiently common pattern to merit adding a standard way to work with it.
> For this all to work, it's very important that there is a default
> return value representing a failure,
It's not important that it must be some tangible default value. It's important that there is a distinct "failed" state. As I say, why not return an optional? That has a well-defined failure state which is agnostic to the type being returned.
> I'll try write code that has
> a static-duration (or thread-local duration) promise and future
> object, and then re-use these objects
Which then limits you to a maximum of one "active" task at once with additional boilerplate to work around (plus lifetime and other issues).
But in the nicest possible way, I'm still not seeing motivation. You've explained *what* the proposal is and you've explained your specific use-case, but that's not *why* this is needed. std::async already has a well-defined error handler in throwing an exception. Tasks which fail have a well defined failure state, either in the semantic of their function or by throwing an exception which itself gets rethrown in the call to get(). Why is your spin on it better? What does it offer that dealing with the exceptions doesn't?
> (which is very rare), or the thread might freeze up or fail in some
> way.
In what way? If after std::async is finished "setting up the asynchronous task", the thread it spawns may freeze or fail, what causes that in your use-case? And in what way does your proposed implementation solve that? As always forgive me if I'm mistaken but as far as I can see the only exceptions and failures your suggestion seems to deal with are exclusively related to the call to async, and anything which happens when executing the task is outside the scope of this change.
> If this wait operation times out, or if the value of the future object
> is 0 (corresponding to the 128-Bit UUID
> 00000000-0000-0000-0000-000000000000), then I abandon the future
> object and start again with a new thread and a new future object. I'll
> have a global container of future objects and allow it to get to N
> size before my program tells the user "You need to close the program
> and re-start it".
This sounds a lot like deducing the success or failure of an asynchronous task based some a timer recording it in another thread. Is that not inherently susceptible to race conditions affecting your logic should the scheduler decide to sleep either thread? Indeed is this not a possible cause of your "freezing up or failing in some way"? In any case, I'm not sure that the program design of stacking up enough failed threads/asyncs that the program requires a manual restart to clear itself out is a sufficiently common pattern to merit adding a standard way to work with it.
> For this all to work, it's very important that there is a default
> return value representing a failure,
It's not important that it must be some tangible default value. It's important that there is a distinct "failed" state. As I say, why not return an optional? That has a well-defined failure state which is agnostic to the type being returned.
> I'll try write code that has
> a static-duration (or thread-local duration) promise and future
> object, and then re-use these objects
Which then limits you to a maximum of one "active" task at once with additional boilerplate to work around (plus lifetime and other issues).
But in the nicest possible way, I'm still not seeing motivation. You've explained *what* the proposal is and you've explained your specific use-case, but that's not *why* this is needed. std::async already has a well-defined error handler in throwing an exception. Tasks which fail have a well defined failure state, either in the semantic of their function or by throwing an exception which itself gets rethrown in the call to get(). Why is your spin on it better? What does it offer that dealing with the exceptions doesn't?
Received on 2023-11-07 18:45:47