Implement io_service::process_events_until_complete #69
Conversation
| @@ -117,8 +117,8 @@ namespace cppcoro | |||
| // State transition diagram | |||
| // VNRCA - value_not_ready_consumer_active | |||
| // VNRCS - value_not_ready_consumer_suspended | |||
| // VRPA - value_ready_consumer_active | |||
| // VRPS - value_ready_consumer_suspended | |||
| // VRPA - value_ready_producer_active | |||
| @@ -178,6 +185,26 @@ namespace cppcoro | |||
|
|
|||
| }; | |||
|
|
|||
| template<typename TASK> | |||
| decltype(auto) io_service::process_events_until_complete(TASK&& task) | |||
There was a problem hiding this comment.
This implementation should work just fine for the cases where there is only a single thread processing events, but if there are multiple threads processing events then calling stop() when the task completes can potentially lead those other threads to exit their event loops too (whether or not they do actually exit is racy since the waiting thread calls reset() without necessarily waiting for all other threads to exit their loops). Ideally only the current thread would exit the event loop in this case.
To implement support for this behaviour would require integration into the core event loop within io_service to allow it to check the status of the task/awaitable after processing each IOCP event. It would also likely need to use a short timeout on the call to GetQueuedCompletionStatus() to allow it to poll for the task/awaitable potentially completing on another thread.
It will also need to change a little once the generic_ops branch is merged as the [shared_]task<T>::get_starter() methods and cppcoro::detail::continuation type have both been removed in that work. I'll update the implementation as appropriate when merging this work into the generic_ops branch.
There was a problem hiding this comment.
To be clear, I'm happy with the implementation as it is for now.
I'll think further about whether it makes sense to limit its use to the single-threaded event processing case or to use a more complicated implementation that allows for boost-blocking use-cases with multiple I/O threads.
There was a problem hiding this comment.
I'll try to make it work with multiple threads. I think it may be possible to do it without polling. FWIW I think that this function is semantically similar to sync_wait, so if one is not limited to a single thread, another shouldn't be as well.
|
|
||
| auto task = makeTask(ioService); | ||
|
|
||
| CHECK(ioService.process_events_until_complete(task) == "foo"); |
There was a problem hiding this comment.
Would you be able to add an extra test in here for passing the already-completed task into process_event_until_complete() to test the code-path in the implementation where task.is_ready() returns true?
|
@lewissbaker Sorry I wasn't able to figure out a nice way to make it work with multiple threads. At the project I am working on, we decided to use explicit alternative using Although I've added a test you requested, IMO if it's not possible to make it work nicely with multiple threads, it may be not worth having this merged in. There is already one way to achieve desired behavior anyway. Feel free to close a pull request and you can either cherry pick the commit with typo fix or I can open a new PR, whichever is easiest for you. |
|
@Uran198 Thanks for the update. I've cherry-picked the typo fix into master. I'll think more about the |
Closes #30