Bug #1717: Thread local variables not visible from within a Fiber

• Status: Rejected
• Assignee: -
• ruby -v: ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]

[oldmoe (Muhammad Ali)]

=begin

Given the following:

Thread.current[:x] = 1

Fiber.new{Thread.current[:x]}.resume # => nil

returns nil when it should return 1

even though Thread.current returns the same object

=end

[rogerdpack (Roger Pack)]

=begin
does this work in trunk?
=r
=end

[mame (Yusuke Endoh)]

=begin
Hi,

2009/7/3 Muhammad Ali [e-mail]:

Thread.current[:x] = 1

Fiber.new{Thread.current[:x]}.resume # => nil

returns nil when it should return 1

even though Thread.current returns the same object

I've heard that this is intentional. Thread.current is both
thread-local and fiber-local storage.

I can't really remember the rationale, but I think that most of
legacy libraries that uses thread-local storage will expect the
storage to be also fiber-local.

--
Yusuke ENDOH [e-mail]

=end

[oldmoe (Muhammad Ali)]

=begin
That makes sense, but I had a need to share data across fibers running in
the same thread, shouldn't there be a way to get hold to the parent thread's
local storage?

oldmoe

On Sun, Jul 12, 2009 at 7:21 AM, Yusuke ENDOH [e-mail] wrote:

Hi,

2009/7/3 Muhammad Ali [e-mail]:

Thread.current[:x] = 1

Fiber.new{Thread.current[:x]}.resume # => nil

returns nil when it should return 1

even though Thread.current returns the same object

I've heard that this is intentional. Thread.current is both
thread-local and fiber-local storage.

I can't really remember the rationale, but I think that most of
legacy libraries that uses thread-local storage will expect the
storage to be also fiber-local.

--
Yusuke ENDOH [e-mail]

That makes sense, but I had a need to share data across fibers running in the same thread, shouldn't there be a way to get hold to the parent thread's local storage?

oldmoe

On Sun, Jul 12, 2009 at 7:21 AM, Yusuke ENDOH <[e-mail]> wrote:

Hi,

2009/7/3 Muhammad Ali <[e-mail]>:

> Thread.current[:x] = 1
>
> Fiber.new{Thread.current[:x]}.resume # => nil
>
> # returns nil when it should return 1
> # even though Thread.current returns the same object

I've heard that this is intentional.  Thread.current is both
thread-local and fiber-local storage.

I can't really remember the rationale, but I think that most of
legacy libraries that uses thread-local storage will expect the
storage to be also fiber-local.

--
Yusuke ENDOH <[e-mail]>

=end

[wycats (Yehuda Katz)]

=begin
You could do:

t = Thread.new(Thread.current) do |parent|
# access to parent
end

It seems that having fibers have their own Thread.local is a good thing; otherwise, people who store local things inside of Thread-local variables could have their details suddenly swapped out in certain circumstances.

You could even do:

class Thread
def self.inherit
parent = Thread.current
new do
parent.keys.each do |key|
next if key =~ /^__/
Thread.current[key] = parent[key]
end
yield
end
end
end

Which would be used like Thread.new, but automatically copy the parent's thread-locals to the new thread.
=end

[naruse (Yui NARUSE)]

• Status changed from Open to Rejected

=begin

=end