-
Notifications
You must be signed in to change notification settings - Fork 67
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
Add condition variables and concurrent-mutexes #210
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - I agree we need something like these. But we should be careful not to simply copy the Lwt API, as we know it has problems!
I find Lwt_condition
s tend to be misused. I've been wondering about splitting them into two separate concepts:
- Events (no payload).
- Variables (store a value; notify everyone if it changes; you can read the current value).
id = Ctf.mint_id ()} | ||
|
||
let wait ?mutex t = | ||
Option.iter Eio_mutex.unlock mutex; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have examples of the mutex
argument being used in Lwt code? Unless it's very common, it might be clearer to let the caller do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that it's not common and I took some time to understand what it's doing.
One example is in mirage-vnetif
: TheLortex/mirage-vnetif@9b38e59#diff-f1be8e184de1d6478035d749a7d4e1099f4accac53644d09a68f12d6c90b0ec3R97
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that use of a mutex looks unnecessary. Incrementing, decrementing and checking an int
field are all atomic anyway with Lwt.
And remove some is_empty API from mutex
I think the main question here is whether to make conditions safe to use across domains or not. A condition that's only used in a single domain can have a simpler API, because when However, if it's used across domains then the API needs to take a mutex because the caller needs to prevent other domains from changing the variable until it has finished using it. So maybe we need two different modules here (e.g. |
Needs rebasing now that #223 is merged. |
(fixed in #277) |
Hi, when porting the lwt-based Mirage networking stack to
eio
I have encountered an extensive use of theLwt_condition and Lwt_mutex modules. This PR adds eio-equivalents:
Condition
andEio_mutex
(Eio_mutex
is prefixed because of the already existingStdlib.Mutex
).Both features have straightforward implementations by using existing modules (
Semaphore
/Waiters
) but I think it can ease the transition fromlwt
toeio
to have them.This is obviously open for discussion.