(no subject)

[David A. Black]

Hi --

I'm trying to get a fix on thread behavior in 1.9 vs. 1.8.6, and the
following things seem odd to me (unless I've just slept through some
known changes, which is always possible).

Doing this:

$ ruby19 -ve 'Thread.new { puts "a" }'
ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]

always results in no output (except the version).

The same thing in 1.8.6 always puts's "a":

$ ruby -ve 'Thread.new { puts "a" }'
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.10.1]
a

So I figure that somehow the killing of the new thread upon exit is
"winning" over the execution of the thread. I guess that's OK (?).
Anyway, this tends to support that interpretation:

$ ruby19 -e 'Thread.new { puts "a" }; sleep 0.01'
a

I then did a few more little tests. I'm leaving in all the -v stuff,
since that's how it was, but the main point is that 1.8.6 seems to
always do this:

$ ruby -ve 'Thread.new { puts "a" }; puts "b"'
ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.10.1]
a
b

while 1.9 does a variety of things, presumably depending on
scheduling:

$ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
ba

$ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
b
$ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
ba

$ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
ba
$

(That last one had both letters but only one newline.)

I'm not quite sure what all of this adds up to, in terms of predicting
thread behavior at or near the end of a program. That one can't? :-)


David

-- 
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details, and stay
tuned for dates in Berlin!

Re: threads at end of programs in 1.8/1.9

[David A. Black]

Whoops, no subject line -- I'm adding one.

On Wed, 20 Feb 2008, David A. Black wrote:

> Hi --
>
> I'm trying to get a fix on thread behavior in 1.9 vs. 1.8.6, and the
> following things seem odd to me (unless I've just slept through some
> known changes, which is always possible).
>
> Doing this:
>
> $ ruby19 -ve 'Thread.new { puts "a" }'
> ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
>
> always results in no output (except the version).
>
> The same thing in 1.8.6 always puts's "a":
>
> $ ruby -ve 'Thread.new { puts "a" }'
> ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.10.1]
> a
>
> So I figure that somehow the killing of the new thread upon exit is
> "winning" over the execution of the thread. I guess that's OK (?).
> Anyway, this tends to support that interpretation:
>
> $ ruby19 -e 'Thread.new { puts "a" }; sleep 0.01'
> a
>
> I then did a few more little tests. I'm leaving in all the -v stuff,
> since that's how it was, but the main point is that 1.8.6 seems to
> always do this:
>
> $ ruby -ve 'Thread.new { puts "a" }; puts "b"'
> ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.10.1]
> a
> b
>
> while 1.9 does a variety of things, presumably depending on
> scheduling:
>
> $ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
> ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
> ba
>
> $ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
> ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
> b
> $ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
> ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
> ba
>
> $ ruby19 -ve 'Thread.new { puts "a" }; puts "b"'
> ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
> ba
> $
>
> (That last one had both letters but only one newline.)
>
> I'm not quite sure what all of this adds up to, in terms of predicting
> thread behavior at or near the end of a program. That one can't? :-)
>
>
> David
>
> -- 
> Upcoming Rails training from David A. Black and Ruby Power and Light:
>  ADVANCING WITH RAILS, April 14-17 2008, New York City
>  CORE RAILS, June 24-27 2008, London (Skills Matter)
> See http://www.rubypal.com for details, and stay
> tuned for dates in Berlin!
>

-- 
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details, and stay
tuned for dates in Berlin!

Re: threads at end of programs in 1.8/1.9

[Yukihiro Matsumoto]

Hi,

In message "Re: threads at end of programs in 1.8/1.9"
    on Wed, 20 Feb 2008 05:04:42 +0900, "David A. Black" <dblack@rubypal.com> writes:

|> I'm trying to get a fix on thread behavior in 1.9 vs. 1.8.6, and the
|> following things seem odd to me (unless I've just slept through some
|> known changes, which is always possible).
|>
|> Doing this:
|>
|> $ ruby19 -ve 'Thread.new { puts "a" }'
|> ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
|>
|> always results in no output (except the version).

The pthread context switching is far more complex than the green
thread in 1.8, so that it is tougher to predict.  I think the
complexity has its own good reason.

|> I'm not quite sure what all of this adds up to, in terms of predicting
|> thread behavior at or near the end of a program. That one can't? :-)

I am afraid that ensuring the simple predictability may hinder the
threading performance.

							matz.

Re: threads at end of programs in 1.8/1.9

[David A. Black]

Hi --

On Wed, 20 Feb 2008, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: threads at end of programs in 1.8/1.9"
>    on Wed, 20 Feb 2008 05:04:42 +0900, "David A. Black" <dblack@rubypal.com> writes:
>
> |> I'm trying to get a fix on thread behavior in 1.9 vs. 1.8.6, and the
> |> following things seem odd to me (unless I've just slept through some
> |> known changes, which is always possible).
> |>
> |> Doing this:
> |>
> |> $ ruby19 -ve 'Thread.new { puts "a" }'
> |> ruby 1.9.0 (2008-02-15 revision 0) [i686-darwin9.1.0]
> |>
> |> always results in no output (except the version).
>
> The pthread context switching is far more complex than the green
> thread in 1.8, so that it is tougher to predict.  I think the
> complexity has its own good reason.
>
> |> I'm not quite sure what all of this adds up to, in terms of predicting
> |> thread behavior at or near the end of a program. That one can't? :-)
>
> I am afraid that ensuring the simple predictability may hinder the
> threading performance.

OK -- I just wanted to be sure I was interpreting it correctly.
Thanks.


David

-- 
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details, and stay
tuned for dates in Berlin!

Re:

[Ripta Pasay]

On Wed, 20 Feb 2008 05:01:13 +0900, "David A. Black" <dblack@rubypal.com>
wrote:
> (That last one had both letters but only one newline.)
> 
> I'm not quite sure what all of this adds up to, in terms of predicting
> thread behavior at or near the end of a program. That one can't? :-)
> 
> 
> David
> 
> --


Was order of execution in Thread ever guaranteed? The output, for instance,
is different between my two machines, even on the same version of ruby:

    $ ruby -ve 'Thread.new { puts "a" }; puts "b"'
    ruby 1.9.0 (2008-02-16 revision 3) [i686-linux]
    b

    $ ruby -ve 'Thread.new { puts "a" }; puts "b"'
    ruby 1.9.0 (2008-02-16 revision 3) [i686-darwin8.9.1]
    ba

If I needed to ensure a thread finishes before exiting, I would #join it. 

-Ripta

Re: threads at end of programs in 1.8/1.9

[MenTaLguY]

On Wed, 20 Feb 2008 05:29:29 +0900, "David A. Black" <dblack@rubypal.com> wrote:
>> |> I'm not quite sure what all of this adds up to, in terms of
> predicting
>> |> thread behavior at or near the end of a program. That one can't? :-)
>>
>> I am afraid that ensuring the simple predictability may hinder the
>> threading performance.
> 
> OK -- I just wanted to be sure I was interpreting it correctly.
> Thanks.

I think it sort of falls under the general rule where if you want two
threads to have predictable behavior with respect to one another, then
you must establish synchronization between them (in this case, the
appropriate synchronization primitive being Thread#join).

-mental

Re:

[David A. Black]

Hi --

On Wed, 20 Feb 2008, Ripta Pasay wrote:

>
>
> On Wed, 20 Feb 2008 05:01:13 +0900, "David A. Black" <dblack@rubypal.com>
> wrote:
>> (That last one had both letters but only one newline.)
>>
>> I'm not quite sure what all of this adds up to, in terms of predicting
>> thread behavior at or near the end of a program. That one can't? :-)
>>
>>
>> David
>>
>> --
>
>
> Was order of execution in Thread ever guaranteed? The output, for instance,
> is different between my two machines, even on the same version of ruby:
>
>    $ ruby -ve 'Thread.new { puts "a" }; puts "b"'
>    ruby 1.9.0 (2008-02-16 revision 3) [i686-linux]
>    b
>
>    $ ruby -ve 'Thread.new { puts "a" }; puts "b"'
>    ruby 1.9.0 (2008-02-16 revision 3) [i686-darwin8.9.1]
>    ba
>
> If I needed to ensure a thread finishes before exiting, I would #join it.

i don't think it was guaranteed but I was seeing patterns of results
in 1.8.6 that were very different (and in some cases less patterned)
than in 1.9. I agree, though: the comparatively predictable behavior
in 1.8 doesn't mean that there's any automatic joining of threads
going on. I was just curious about the differences.


David

-- 
Upcoming Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS, April 14-17 2008, New York City
   CORE RAILS, June 24-27 2008, London (Skills Matter)
See http://www.rubypal.com for details, and stay
tuned for dates in Berlin!