-
Notifications
You must be signed in to change notification settings - Fork 165
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
Remove unneeded concurrency things #360
Conversation
The gist of this is I'm looking into why we have some nasty corner cases. This isn't it, but it's a slight optimization that could be made wrt the flow handling |
@lowasser Just checking in to see if this project is still alive or if you have any questions/concerns on this? |
@jamesward Thoughts on this? |
We will need @lowasser to review this. |
Ok. The idea here is none of these mutexes or atomicBooleans are ever used concurrently they're very sequential in their nature, so having the lock there doesn't accomplish anything. |
This does look safe to me. |
The mutex and atomicBolean aren't needed in this context.
The mutex is only contained in a local variable in sequential code. It isn't shared w/ any other threads. The same with the atomic bolean.
Both of these constructs are inside the launched co-routine, and aren't shared outside. Therefore they can't help control any other shared access.