Project

General

Profile

Bug #1717

Thread local variables not visible from within a Fiber

Added by oldmoe (Muhammad Ali) over 9 years ago. Updated over 7 years ago.

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

Description

=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


Related issues

Has duplicate Ruby trunk - Bug #5750: Thread.current local-variables behaviorClosed2011-12-12

History

#1 Updated by rogerdpack (Roger Pack) over 9 years ago

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

#2 Updated by mame (Yusuke Endoh) over 9 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

#3 Updated by oldmoe (Muhammad Ali) over 9 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

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>

=end

#4 Updated by wycats (Yehuda Katz) over 9 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

#5 Updated by naruse (Yui NARUSE) about 9 years ago

  • Status changed from Open to Rejected

=begin

=end

Also available in: Atom PDF