Project

General

Profile

Actions

Bug #1717

closed

Thread local variables not visible from within a Fiber

Added by oldmoe (Muhammad Ali) over 15 years ago. Updated over 13 years ago.

Status:
Rejected
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 1 (0 open1 closed)

Has duplicate Ruby master - Bug #5750: Thread.current local-variables behaviorClosedakr (Akira Tanaka)12/12/2011Actions
Actions #1

Updated by rogerdpack (Roger Pack) over 15 years ago

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

Actions #2

Updated by mame (Yusuke Endoh) over 15 years ago

=begin
Hi,

2009/7/3 Muhammad Ali :

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

=end

Actions #3

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 wrote:

Hi,

2009/7/3 Muhammad Ali :

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

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 <> wrote:
Hi,

2009/7/3 Muhammad Ali <>:
> 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 <>


=end

Actions #4

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

Actions #5

Updated by naruse (Yui NARUSE) about 15 years ago

  • Status changed from Open to Rejected

=begin

=end

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0