[#47787] Ruby Parallelism — Miguel Palhas <mpalhas@...>
Greetings
4 messages
2012/10/01
[#47790] [ruby-trunk - Bug #7097][Open] Thread locals don't work inside Enumerator — "tenderlovemaking (Aaron Patterson)" <aaron@...>
32 messages
2012/10/01
[#47791] [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator
— "kosaki (Motohiro KOSAKI)" <kosaki.motohiro@...>
2012/10/01
[#47792] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator
— Aaron Patterson <tenderlove@...>
2012/10/01
On Tue, Oct 02, 2012 at 03:05:17AM +0900, kosaki (Motohiro KOSAKI) wrote:
[#47798] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator
— SASADA Koichi <ko1@...>
2012/10/01
(2012/10/02 3:12), Aaron Patterson wrote:
[#47800] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator
— SASADA Koichi <ko1@...>
2012/10/01
(2012/10/02 8:22), SASADA Koichi wrote:
[#47802] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator
— Aaron Patterson <tenderlove@...>
2012/10/02
On Tue, Oct 02, 2012 at 08:32:51AM +0900, SASADA Koichi wrote:
[#47807] Re: [ruby-trunk - Bug #7097][Assigned] Thread locals don't work inside Enumerator
— KOSAKI Motohiro <kosaki.motohiro@...>
2012/10/02
>> For example:
[#48291] [ruby-trunk - Bug #7097] Thread locals don't work inside Enumerator
— "tenderlovemaking (Aaron Patterson)" <aaron@...>
2012/10/25
[#48299] Re: [ruby-trunk - Bug #7097] Thread locals don't work inside Enumerator
— SASADA Koichi <ko1@...>
2012/10/26
I don't have any objection.
[#48300] Re: [ruby-trunk - Bug #7097] Thread locals don't work inside Enumerator
— Aaron Patterson <tenderlove@...>
2012/10/26
On Fri, Oct 26, 2012 at 02:40:53PM +0900, SASADA Koichi wrote:
[#47832] [ruby-trunk - Feature #7106][Open] FileUtils.touch should allow touching the symlink itself rather than the file the link points to — "cirrusthinking (Alessandro Diaferia)" <alessandro@...>
18 messages
2012/10/04
[#47841] [ruby-trunk - Bug #7109][Open] File.utime doesn't set nanoseconds — "bkabrda (Bohuslav Kabrda)" <bkabrda@...>
6 messages
2012/10/05
[#47842] Re: [ruby-trunk - Bug #7109][Open] File.utime doesn't set nanoseconds
— Tanaka Akira <akr@...>
2012/10/05
2012/10/5 bkabrda (Bohuslav Kabrda) <[email protected]>:
[#47847] [ruby-trunk - Bug #7110][Open] CGI: Add support for HTML5 <header> tag — "stomar (Marcus Stollsteimer)" <redmine@...>
16 messages
2012/10/05
[#47880] [ruby-trunk - Bug #7134][Open] Signal handling bug in Mac OS X — "auastro (Andy Kitchen)" <kitchen.andy+rubybug@...>
17 messages
2012/10/10
[#48918] [ruby-trunk - Bug #7134][Assigned] Signal handling bug in Mac OS X
— "mame (Yusuke Endoh)" <mame@...>
2012/11/05
[#47881] [ruby-trunk - Bug #7135][Open] GC bug in Ruby 1.9.3-p194? — "alexdowad (Alex Dowad)" <alexinbeijing@...>
21 messages
2012/10/10
[#47887] [ruby-trunk - Bug #7137][Open] Date.parse overly lenient when attempting to parse Monday? — "garysweaver (Gary Weaver)" <garysweaver@...>
12 messages
2012/10/10
[#47927] new ruby 1.9.3 maintainer — "U.Nakamura" <usa@...>
Hello everyone of the Ruby development community
6 messages
2012/10/12
[#47930] [ruby-trunk - Feature #7148][Open] Improved Tempfile w/o DelegateClass — "Glass_saga (Masaki Matsushita)" <glass.saga@...>
14 messages
2012/10/12
[#47963] [ruby-trunk - Bug #7154][Open] For whatever reason \s doesn't match \u00a0. — "t0d0r (Todor Dragnev)" <todor.dragnev@...>
5 messages
2012/10/13
[#47970] [ruby-trunk - Bug #7158][Open] require is slow in its bookkeeping; can make Rails startup 2.2x faster — "gregprice (Greg Price)" <price@...>
30 messages
2012/10/14
[#48504] [ruby-trunk - Bug #7158] require is slow in its bookkeeping; can make Rails startup 2.2x faster
— "h.shirosaki (Hiroshi Shirosaki)" <h.shirosaki@...>
2012/10/27
[#48505] Re: [ruby-trunk - Bug #7158] require is slow in its bookkeeping; can make Rails startup 2.2x faster
— SASADA Koichi <ko1@...>
2012/10/27
(2012/10/28 7:10), h.shirosaki (Hiroshi Shirosaki) wrote:
[#48728] [ruby-trunk - Bug #7158] require is slow in its bookkeeping; can make Rails startup 2.2x faster
— "tenderlovemaking (Aaron Patterson)" <aaron@...>
2012/11/02
[#48732] Re: [ruby-trunk - Bug #7158] require is slow in its bookkeeping; can make Rails startup 2.2x faster
— Masaya TARUI <tarui@...>
2012/11/02
Thank you for the careful work.
[#48032] [Backport93 - Backport #7174][Open] Advocating for backporting 36811 — "jonforums (Jon Forums)" <redmine@...>
8 messages
2012/10/16
[#48086] [Backport93 - Backport #7174][Assigned] Advocating for backporting 36811
— "usa (Usaku NAKAMURA)" <usa@...>
2012/10/19
[#48040] Should Hash#dup automatically rehash — Aaron Patterson <tenderlove@...>
Hi,
5 messages
2012/10/17
[#48072] [ruby-trunk - Bug #7184][Open] --disable-gems commandline parameter does not show up with ruby -h — "steenslag (siep korteling)" <s.korteling@...>
10 messages
2012/10/18
[#48132] [ruby-trunk - Bug #7201][Open] Setting default_external affects STDIN encoding but default_internal does not — "brixen (Brian Ford)" <brixen@...>
6 messages
2012/10/21
[#48154] Patch to test_ssl to validate server-side support for SNI — Patrick Toomey <ptoomey3@...>
I recently made a pull request to JRuby (
4 messages
2012/10/22
[#48675] Re: Patch to test_ssl to validate server-side support for SNI
— Charles Oliver Nutter <headius@...>
2012/10/31
We have incorporated Patrick's SNI patch for upcoming release JRuby
[#48191] [ANN] 2.0.0 feature freeze — Yusuke Endoh <mame@...>
Japanese later; 日本語は後で
37 messages
2012/10/24
[#48197] Re: [ANN] 2.0.0 feature freeze
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/10/24
Em 24-10-2012 09:39, Yusuke Endoh escreveu:
[#48696] Re: [ANN] 2.0.0 feature freeze
— SASADA Koichi <ko1@...>
2012/11/01
(2012/10/24 5:39), Yusuke Endoh wrote:
[#48701] Re: [ANN] 2.0.0 feature freeze
— Yusuke Endoh <mame@...>
2012/11/01
Hello ko1,
[#48712] Re: [ANN] 2.0.0 feature freeze
— Marc-Andre Lafortune <ruby-core-mailing-list@...>
2012/11/01
Hi,
[#48713] Re: [ANN] 2.0.0 feature freeze
— Yusuke Endoh <mame@...>
2012/11/01
AFAIK matz has not accepted #6636 completely yet.
[#48797] Re: [ANN] 2.0.0 feature freeze
— Clay Trump <clay.trump@...>
2012/11/03
Sorry, late to the party, but what's the status of #6679?
[#48798] Re: [ANN] 2.0.0 feature freeze
— =?KOI8-R?B?4NLJyiDzz8vPzM/X?= <funny.falcon@...>
2012/11/03
What status of #6638 <https://bugs.ruby-lang.org/issues/6638>
[#48260] [ruby-trunk - Bug #7214][Open] Ruby 2.0 breaks support for some debugging tools — "banister (john mair)" <jrmair@...>
22 messages
2012/10/25
[#49657] [ruby-trunk - Bug #7214] Ruby 2.0 breaks support for some debugging tools
— "denofevil (Dennis Ushakov)" <dennis.ushakov@...>
2012/11/20
[#48292] [ruby-trunk - Bug #7216][Open] object.c defines clone method for objects that cannot be cloned. — "therevmj (Michael Johnson)" <mj@...>
6 messages
2012/10/26
[#48315] [ruby-trunk - Bug #7220][Open] StringIO#initialize_copy causes aliasing between the objects — "brixen (Brian Ford)" <brixen@...>
13 messages
2012/10/26
[#48475] [ruby-trunk - Feature #3222] Can bignums have singleton class & methods? — "matz (Yukihiro Matsumoto)" <matz@...>
4 messages
2012/10/27
[#48497] Re: [ruby-trunk - Feature #3222] Can bignums have singleton class & methods?
— SASADA Koichi <ko1@...>
2012/10/27
(2012/10/27 23:25), matz (Yukihiro Matsumoto) wrote:
[#48551] [ruby-trunk - Feature #7241][Open] Enumerable#to_h proposal — "nathan.f77 (Nathan Broadbent)" <nathan.f77@...>
23 messages
2012/10/29
[#48587] [ruby-trunk - Feature #7241] Enumerable#to_h proposal
— "rosenfeld (Rodrigo Rosenfeld Rosas)" <rr.rosas@...>
2012/10/30
[#48625] Re: [ruby-trunk - Feature #7241] Enumerable#to_h proposal
— Aaron Patterson <tenderlove@...>
2012/10/30
On Tue, Oct 30, 2012 at 07:58:33PM +0900, rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
[#48631] Re: [ruby-trunk - Feature #7241] Enumerable#to_h proposal
— Rodrigo Rosenfeld Rosas <rr.rosas@...>
2012/10/30
Em 30-10-2012 16:23, Aaron Patterson escreveu:
[#48679] [ruby-trunk - Feature #905] Add String.new(fixnum) to preallocate large buffer — "headius (Charles Nutter)" <headius@...>
4 messages
2012/10/31
[ruby-core:48312] Re: [ruby-trunk - Bug #7097] Thread locals don't work inside Enumerator
From:
Aaron Patterson <tenderlove@...>
Date:
2012-10-26 17:36:04 UTC
List:
ruby-core #48312
On Fri, Oct 26, 2012 at 11:38:19PM +0900, Eregon (Benoit Daloze) wrote:
>
> Issue #7097 has been updated by Eregon (Benoit Daloze).
>
>
> tenderlovemaking (Aaron Patterson) wrote:
> > I spoke with ko1-san and Usa-san last night, and we thought that thread_variable_(get|set) would be good (similar to instance_variable_(get|set)). I've attached an updated patch to make that change. The documentation includes examples of how the thread local storage and fiber local storage are different.
> >
> > I added two more methods:
> >
> > * Thread#thread_variables # => returns a list of the defined variable keys
> > * Thread#thread_variable? # => returns true if a key is set, otherwise false
> >
> > Thread#local_variable_(get|set) methods respect the same security and frozen behavior as Thread#[] and Thread#[]=.
>
> Sounds great, but I feel the "thread_" prefix is redundant given it is called on a Thread object.
> I'm thinking to two alternatives:
>
> * Remove the "thread_" prefix (as usually the thread instance is Thread.current which is very explicit, or the variable name should be clear enough).
>
> Thread.current.variable_get(:var)
> thread.variable_get(:var)
> worker.variable_get(:var)
> # versus
> Thread.current.thread_variable_get(:var)
> thread.thread_variable_get(:var)
> worker.thread_variable_get(:var)
>
> Also, I think get/set do not feel very ruby-like, so ...
If it becomes cumbersome, we can add aliases later. get/set aren't very
ruby-like, but we have other examples (instance_variable_(get|set)).
> * Use a API resembling fiber locals:
>
> Thread#locals # => returns an object responding to #[] and #[]= (and maybe #variables and #include?)
>
> Thread.current.locals[:var] = some_value
> Thread.current.locals[:var]
>
> I guess exposing the whole Hash is exposing internal structures and so is unreasonable. But doing so would be intuitive and avoid having 4 new methods for 4 well-known ([],[]=,keys,include?).
I'd rather not expose another object. We can't just expose the hash
object because it would have inconsistent behavior with fiber locals:
irb(main):001:0> t = Thread.new { }.join
=> #<Thread:0x007fe5f11278c8 dead>
irb(main):002:0> t[:foo] = "bar"
=> "bar"
irb(main):003:0> t["foo"]
=> "bar"
irb(main):004:0>
Also, we'd have to figure out what calling `freeze` on that hash means.
Because of these things, we would have to expose a new object that isn't
a Hash. Exposing a new object means propagating things like
Thread#freeze down to the new object.
If we implement these 4 new method in my patch, our API footprint is
only increased by 4 new methods (vs 5 methods + a new object type). If
we find later on that exposing an object is a good thing, we can easily
implement these 4 methods in terms of the new object and deprecate the
4 methods. Going in the other direction, deprecating an object, is not
so easy.
I don't particularly care what the method names are (since we can just
alias them later), but I'm firmly against exposing a new object.
--
Aaron Patterson
http://tenderlovemaking.com/