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

Initialize the monitor for new subarrays on Rubinius #665

Merged
merged 1 commit into from Jul 23, 2017

Conversation

3 participants
@meineerde
Contributor

meineerde commented Jul 3, 2017

This pull request should fix #559.

Rubinius uses the public methods new_range and new_reserved to
create new sub-arrays in methods like Array#slice, Array#[](range)
or similar.

Here, Rubinius does not call Array.allocate to create the new object
resulting in the monitor not being initialized which then causes errors
like

NoMethodError: undefined method `synchronize' on nil:NilClass.

when calling any methods of the new sub-array. By overwriting the two
methods and explicitly initializing the monitor there, we can ensure
that the monitor is always initialized correctly.

Initialize the monitor for new subarrays on Rubinius
Rubinius uses the public methods `new_range` and `new_reserved` to
create new sub-arrays in methods like `Array#slice`, `Array#[](range)`
or similar.

Here, Rubinius does not call `Array.allocate` to create the new object
resulting in the monitor not being initialized which then causes errors
like

    NoMethodError: undefined method `synchronize' on nil:NilClass.

when calling any methods of the new sub-array. By overwriting the two
methods and explicitly initializing the monitor there, we can ensure
that the monitor is always initialized correctly.
@meineerde

This comment has been minimized.

Show comment
Hide comment
@meineerde

meineerde Jul 4, 2017

Contributor

For reference, Array#new_range is defined in core/array.rb#L15-L18 resp. machine/class/array.cpp#L66-L103.

It is used in e.g. Array#[] to construct a new sub-array in core/array.rb#L307.

Contributor

meineerde commented Jul 4, 2017

For reference, Array#new_range is defined in core/array.rb#L15-L18 resp. machine/class/array.cpp#L66-L103.

It is used in e.g. Array#[] to construct a new sub-array in core/array.rb#L307.

@@ -14,5 +14,15 @@ module Concurrent
end
end.map(&:join)
end
describe '#slice' do
# This is mostly relevant on Rubinius and Truffle

This comment has been minimized.

@eregon

eregon Jul 15, 2017

Contributor

FWIW TruffleRuby tries to avoid extra public methods, so new_range/new_reserved are not defined on Array in TruffleRuby.
Arguably, this is a Rubinius bug to expose internal methods as public.

@eregon

eregon Jul 15, 2017

Contributor

FWIW TruffleRuby tries to avoid extra public methods, so new_range/new_reserved are not defined on Array in TruffleRuby.
Arguably, this is a Rubinius bug to expose internal methods as public.

This comment has been minimized.

@meineerde

meineerde Jul 15, 2017

Contributor

The problem is not so much that this method is public rather than that they are "special" to Rubinius in that they create objects without calling allocate. They would still have to be overwritten by concurrent-ruby if they were private, although it would have to be done slightly different...

As for the comment itself, I have not tested this on Truffle nor have I specifically checked their implementation to be honest. The comment might thus be not 100% exact in this regard. However, since the monitor is only used on Rubinius and Truffle at all, the test still applies to this locking variant used here.

@meineerde

meineerde Jul 15, 2017

Contributor

The problem is not so much that this method is public rather than that they are "special" to Rubinius in that they create objects without calling allocate. They would still have to be overwritten by concurrent-ruby if they were private, although it would have to be done slightly different...

As for the comment itself, I have not tested this on Truffle nor have I specifically checked their implementation to be honest. The comment might thus be not 100% exact in this regard. However, since the monitor is only used on Rubinius and Truffle at all, the test still applies to this locking variant used here.

@pitr-ch

Looks good thanks for your contribution!

@pitr-ch pitr-ch merged commit df482db into ruby-concurrency:master Jul 23, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment