Project

General

Profile

Actions

Bug #5750

closed

Thread.current local-variables behavior

Added by schmurfy (Julien A) over 12 years ago. Updated over 11 years ago.

Status:
Closed
Target version:
-
ruby -v:
1.9.3-p0
Backport:
[ruby-core:41606]

Description

Hi, I stumbled upon something which for me is a bug and wanted to check if it is working as intended or not:

Thread.current[:a] = 1
p Thread.current[:a] # => 1

Fiber.new do
 p Thread.current[:a] # => nil
end.resume

There is clearly a problem in either the documentation or the implementation for me there, we are in the same thread yet the returned values are different which is completely counter intuitive...
Why not add a fiber-variables store to allow the following and keep things separated between fibers and threads

Fiber.current[:a] = 1
p Fiber.current[:a] # => 1

Fiber.new do
 p Fiber.current[:a] # => nil
end.resume

Which is now the behavior I would expect.


Related issues 1 (0 open1 closed)

Is duplicate of Backport191 - Bug #1717: Thread local variables not visible from within a FiberRejected07/03/2009Actions

Updated by mame (Yusuke Endoh) over 12 years ago

  • Status changed from Open to Rejected

Hello, thank you for your reporting.

I am not surprised that you are surprised, but it is intentional.

The rationale is because most of legacy libraries that uses thread-
local storage will expect the storage to be also fiber-local.

See also: http://redmine.ruby-lang.org/issues/show/1717

We cannot change this behavior until Ruby 3.0 (unless matz decides
to change it).

Thanks,

--
Yusuke Endoh

Updated by schmurfy (Julien A) over 12 years ago

Although I consider this behavior (and the reason why it was done) completely absurd, how about at least changing the documentation to mention the real behavior of the supposedly thread-local storage ?
Replacing thread-local by fiber-local in the description of Thread[] and Thread[]= makes a lot more sense for me since every thread has its own root fiber, by reading the current documentation I expect my second call to Thread.current[:a] to return 1 not nil which is clearly misleading and could create nice bugs...

The current text is ( for Thread[sym] ):

Attribute Reference—Returns the value of a thread-local variable, using either a symbol or a string name. If the specified variable does not exist, returns nil.

Updated by mame (Yusuke Endoh) over 12 years ago

  • Status changed from Rejected to Open
  • Assignee set to akr (Akira Tanaka)

Sorry, I was stupid. Indeed the documatation has room for improvement.
If I recall correctly, akira tanaka suggested the current behavior.
So I'm reopening and assigning this ticket to him.

--
Yusuke Endoh

Updated by schmurfy (Julien A) over 12 years ago

any news on this ?
This documentation bug is here since 1.9 was first released from what I understand so I think it would be rather urgent to fix it, for me a documentation is even worse than a bug in the codebase since it leads you to think wrongly about how things works.

Updated by ko1 (Koichi Sasada) about 12 years ago

Suggestions are welcome!

Actions #6

Updated by shyouhei (Shyouhei Urabe) about 12 years ago

  • Status changed from Open to Assigned
Actions #7

Updated by akr (Akira Tanaka) over 11 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

This issue was solved with changeset r36269.
Julien, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.


  • thread.c (rb_thread_aref): add explanation for why Thread#[] and
    Thread#[]= are fiber-local and not thread-local.
    reported by Julien A. [ruby-core:41606] [ruby-trunk - Bug #5750]
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0