Bug #1717
closedThread local variables not visible from within a Fiber
Description
Updated by rogerdpack (Roger Pack) over 15 years ago
=begin
does this work in trunk?
=r
=end
Updated by mame (Yusuke Endoh) over 15 years ago
=begin
Hi,
2009/7/3 Muhammad Ali redmine@ruby-lang.org:
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 mame@tsg.ne.jp
=end
Updated by oldmoe (Muhammad Ali) over 15 years ago
=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 mame@tsg.ne.jp wrote:
Hi,
2009/7/3 Muhammad Ali redmine@ruby-lang.org:
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 mame@tsg.ne.jp
Hi,
2009/7/3 Muhammad Ali <redmine@ruby-lang.org>:
> Thread.current[:x] = 1I've heard that this is intentional. Thread.current is both
>
> Fiber.new{Thread.current[:x]}.resume # => nil
>
> # returns nil when it should return 1
> # even though Thread.current returns the same object
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 <mame@tsg.ne.jp>
=end
Updated by wycats (Yehuda Katz) over 15 years ago
=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