Skip to content
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

JSR223 engine bindings not working for a second engine in another thread #5753

Open
gregsh opened this issue May 29, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@gregsh
Copy link

commented May 29, 2019

Environment

org.jruby:jruby-complete:9.2.7.0
macOS 10.14.5

Expected Behavior

Script engine bindings work for any engine in any thread in any order.

Actual Behavior

I've noticed that the first engine always work as expected because org.jruby.runtime.ThreadContext#prepareTopLevel is called once, when the org.jruby.Ruby instance is initialized.

Engines created in other threads get un-prepared ThreadContext and have no bindings because:

  • org.jruby.embed.variable.Constant#inject fails because
  • org.jruby.embed.variable.AbstractVariable#getRubyClass returns null because
  • org.jruby.runtime.ThreadContext#getCurrentStaticScope()#cref is null when "not prepared"

Only LocalContextScope.THREADSAFE mode seem to work as expected.

Proposed Fix

The fix I can come up with after some debugging is to add
context.prepareTopLevel(runtime.objectClass, runtime.topSelf);
call to org.jruby.RubyThread#adoptThread.

@headius

This comment has been minimized.

Copy link
Member

commented Jun 7, 2019

The different modes are rather poorly named. So you are saying only THREADSAFE gives the behavior you are expecting? That would fit my expectation; normally we try to isolate different threads because Ruby does not make a lot of language-level guarantees about concurrency.

@gregsh

This comment has been minimized.

Copy link
Author

commented Jun 10, 2019

@headius What about the proposed one-line fix of mine?

@headius

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

@gregsh It is interesting but I'm not sure why it helps. The "top self" is normally only set up once, on the main thread...but I know we have done some defensive pre-pushing of frames and things that could explain why this helps.

Can you create an example app that shows the problems you're talking about? I'd like to be able to step through it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.