-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undesirable wake-up semantics in Stream.take
#356
Comments
You might be interested in Reagents, which allow these kinds of atomic patterns reliably (but are not currently integrated with Eio). Without something like that, it can't work in the general case (multiple domains), because there is always a period of time after the first I've found it's often easier to have a single stream with multiple writers for cases like this. e.g. open Eio
let main _env =
Switch.run @@ fun sw ->
let s = Stream.create 1 in
Fiber.fork ~sw (fun () -> Fiber.yield (); Stream.add s "A");
Fiber.fork ~sw (fun () -> Fiber.yield (); Stream.add s "B");
let result = Stream.take s in
traceln "result: %S" result;
traceln "S length: %d" (Stream.length s)
let () = Eio_main.run main |
I'm still trying to figure out how to properly articulate this issue, but i believe the following semantics are undesirable:
output:
despite
Stream.take s1
winning theFiber.first
race, and presumably cancellingStream.take s2
, both streams wind up empty. it would be preferable for cancellation to prevents2
from having its element removed, in other words should print:i believe this is because the implementation of stream takes a short cut where adding to an empty stream will pass the item immediately to the "waiter":
eio/lib_eio/stream.ml
Lines 42 to 44 in 63f5896
this gives the reading fiber no ability to respond to a cancellation in time. a modified approach could be to have
readers
beunit Waiters.t
such that this wake up is just a notification that there may be items in the queue, but the fiber still has to manually check the contents again. this check would be enqueued to the scheduler which means that there is an opportunity to cancel it.im not sure if there is an argument to be made in favor of the current semantics, but to me this seems like there is serious potential to lose data when trying to use streams in conjunction with fiber cancellation
The text was updated successfully, but these errors were encountered: