Closed brcharron closed 5 years ago
Once setter task starts running there is nothing to make it pause at any async point if prerequisites for continuous execution is satisfied. So you get that output.
The default behavior of Curio is to never task-switch unless a blocking operation is performed. set()
doesn't normally block so you're not going to see a task switch take place at that point.
This is something that can be changed though. If you want to force a task switch, you could insert an await curio.schedule()
call after the await evt.set()
. If you wanted to hide this detail, you could also inherit from Event
and redefine the set()
method to include the additional curio.schedule()
call.
Thanks a lot for the explanation and implementation suggestion, it works exactly as desired. It seems that curio.schedule()
is not documented but given its one line implementation I guess I could have come up with it if I was more familiar with the concepts...
Hello, I am just starting with curio, loving it so far but I have found some unexpected behavior with events (curio 0.9, python 3.7.3). In the following code I have two "waiters" setting an event each in a queue and a "setter" getting them from the queue and setting them.
The output is
although I would have expected
namely, that the "waiter" processing the event during the
await evt.set()
of the "setter". If this is the expected behavior, how would I get the one I am looking for?