-
Notifications
You must be signed in to change notification settings - Fork 418
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
Deadlock in Concurrent::Array's on non-MRI #627
Comments
Related to #594 |
I think this is a bug. 1) it should behave the same on all implementations. 2) it's a good practice not to execute user code when a lock is taken on a data structure, in this case to execute the each block while the block is taken @thedarkone would you have time to work on this? |
Hi @pitr-ch. |
@GustavoCaso Thanks you very much for you interest. I'll welcome your help. Perhaps you could have a look at #670, it would give you opportunity to read the documentation for the given c-r parts and try it for yourself a with a replacement service you need to find (it can be anything not just finance) for fixing the doc. |
concurrent-ruby
version: 1.0.4concurrent-ruby-ext
installed: noconcurrent-ruby-edge
used: noTake the following code: https://gist.github.com/eregon/323890bfff539f8a33f66d8b2f02cc99
Of course, its purpose is to create a deadlock but it means any method taking a block on Array can cause a deadlock as long as:
Concurrent::Array
by calling a method taking a blockConcurrent::Array
This seems not such a rare scenario, as it is frequent to call methods in a block that do not only involve the current Array.
The deadlock does not happen on MRI, as it uses a single global lock and concurrent-ruby just subclasses
::Array
. It does happen on all other implementations though, like JRuby, Rubinius and TruffleRuby.The documentation says:
So indeed this might imply the deadlock above, but it's not clear.
ensuring only one thread can be reading or writing at a time
is also inaccurate on MRI for methods taking a block, as they release the GIL and might switch to another Thread in the middle of e.g.#each
.The same apply for Hash.
Is this behavior intended? Should this be fixed?
Should it behave the same on the different implementations?
The text was updated successfully, but these errors were encountered: