Skip to content

Present the same Thread object for all fibers within a thread - #1225

Closed
halorgium wants to merge 1 commit into
jruby:masterfrom
halorgium:consistent-thread-between-fibers
Closed

halorgium wants to merge 1 commit into
jruby:masterfrom
halorgium:consistent-thread-between-fibers

Conversation

@halorgium

Copy link
Copy Markdown

There is a bug which I am solving here.
I haven't added a rubyspec. Is this conceptually correct?

@headius

headius commented Nov 17, 2013

Copy link
Copy Markdown
Member

The presentation of thread features to a fiber is really tricky. The reason I have not made this change is because thread local variables do not stay with the parent thread, and are instead local to the fiber.

So there's all sorts of nasty conflicts that I have not figure out how to resolve:

  1. All fibers under a thread have the same Thread.current.
  2. Each fiber has a different set of Thread#[] locals.
  3. Our fiber impl uses Ruby-level thread constructs to handle context switching, so they need to have access to the really real Rubythread.
  4. Each fiber also needs its own ThreadContext for execution state.

There's a number of conflicting goals here, and so far when I have tried to fix the current broken behavior (1 above), I always end up breaking something else (like 2 or 3 above).

This trivial fix resolves 1, but breaks 2 and potentially 3 depending on how Thread.current is used. I'm afraid this is not enough :-(

@headius headius closed this Nov 17, 2013
@halorgium

Copy link
Copy Markdown
Author

@headius thanks for the feedback. Sounds like it needs to be more explicit.
I am keen to push further as a way of learning. Is it OK if I push more changes and questions this way?

@headius

headius commented Nov 26, 2013

Copy link
Copy Markdown
Member

@halorgium Sorry for the delay...but yes, it would be great if you could explore this more. I have not been able to find the magic sauce to mimic MRI behavior, since their behavior doesn't seem consistent with either threaded fibers OR lightweight fibers to me.

headius added a commit to headius/jruby that referenced this pull request Aug 31, 2026
A few step toward getting Thread.current in general to behave like
CRuby, returning the same Thread for all Fiber instances that it
owns.

Behind the scenes, each Fiber is still backed by a VirtualThread
with an associated ThreadContext and RubyThread, but user code
should generally not see those.

Additional fixes will follow for internal code that has
expectations about the current thread of a fiber.

See other attempts to do this and issues related:

* My attempt: jruby#5827
* Community attempt: jruby#1225
* An early issue: jruby#1806

Relates to test failures mentioned in jruby#9603 and
workarounds from users in jruby#9600.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants