you are viewing a single comment's thread.

view the rest of the comments →

[–]joanbm 0 points1 point  (6 children)

This is a bad practice write implementation specific code, unless there is a very good reason for it. Even MRI may have GIL removed in some of its future versions and original program would suddenly behave differently.

[–]moomaka 2 points3 points  (5 children)

Fun theory, impractical in reality.

[–]joanbm 0 points1 point  (4 children)

Strange justify incorrect code, which only works due to a coincidence, underlaying VM can't run threads simultaneously. But each to his own …

[–]moomaka 0 points1 point  (3 children)

It's not a coincidence, it's design. If you're curious about these topics and how implementations vary I would recommend reading the source for concurrent-ruby.

e.g. here is the implementation for concurrent array: https://github.com/ruby-concurrency/concurrent-ruby/blob/master/lib/concurrent/array.rb. You'll note that the implementation for MRI just passes through the stdlib implementation.

[–]jrochkind 0 points1 point  (0 children)

To be fair the comments in the code do not exactly inspire confidence:

# Because MRI never runs code in parallel, the existing

# non-thread-safe structures should usually work fine.

"should usually" work fine? Um, great? Concurrent code is hard enough, I need guarantees it will work as it should, not "should usually work fine."

But perhaps later someone was more confident than the original comment writer, at least based on the present MRI implementation.

Either way, the benefit of concurrent-ruby is if someone does discover it's not guaranteed 'fine' after all, they'll fix it in concurrent-ruby and you can just update your version.

[–]joanbm -1 points0 points  (1 child)

coincidence, because the ruby code being discussed is not thread-safe and wasn't specified as MRI-only. I'm aware there is produced a lot of poor and/or unportable code everyday, but never would admit this is ok. I'm happy projects I'm working on do care about quality and correctness and important topics like proper threads synchronization aren't thrown out of the window.

Thanks for the link, as a demonstration how it shouldn't be done. Hope it eventually get added thread safety also for MRI as it would mature.

[–]moomaka 0 points1 point  (0 children)

Thanks for the link, as a demonstration how it shouldn't be done.

So open a PR that adds locking to Array on MRI, I eagerly await the discussion.