-
Notifications
You must be signed in to change notification settings - Fork 0
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
Race-condition in examples/09? #4
Comments
This is still an issue, by the way, and I've run into it with Paws.rs a little bit. I'm actually not even sure why the examples run just fine on the parallel reactor, because they shouldn't... but maybe things are just executing so quickly that it ends up working? |
Well, this is exactly the thing that, if you look at it one way, stops being an issue, if we're discarding ordering anyway. All this issue is really saying is that the implicit-ordering system that sort of exists in the current spec, really provides nothing useful: if the above example is so flawed that we need to invoke responsibility to make it predictable (which, by the way, is the solution that jumps out at me) … then why not require responsibility in the first place? |
There's a possibly substantial problem, pointed out by @judofyr, in this code from
examples/09.a.routine.paws
:There's nothing to guarantee, on a fast-enough pair of hardware-parallelized stages, that the first-
stage()
'd execution will finish before the second; which means thatlength()
could return the old length, before the affixment has completed.Figure out how to circumvent this inside our current semantics.
The text was updated successfully, but these errors were encountered: