From: Robert Klemme <bob.news@...>
Date: 2004-02-22T08:34:53+09:00
Subject: Re: threads and blocking


"Steve Tuckner" <stevetuckner@yahoo.com> schrieb im Newsbeitrag
news:4037B151.9080204@yahoo.com...
> Joel VanderWerf wrote:
>
> > Shashank Date wrote:
> >
> >> It may have to do with the threads get scheduled to run. For example,
> >> this will block like you expected:
> >>
> >> ruby -e "Thread.new{gets}; Thread.new{sleep(0.01);select nil};
> >> Thread.new{puts 42}"
> >
> >
> > Doesn't block in ruby 1.9.0 (2004-02-15) [i686-linux]. Maybe a windows
> > effect? My (limited) understanding of ruby threads is that thread
> > waiting on IO will not block the app.
> >
> > Also, a thread calling system will not block the app, as in
> >
> >   Thread.new {system "sleep 10"}
> >
> > However, flock does block the process.
> >
> >
> On windows sockets will not generally block Ruby, but if you try a
> TCP#connect on a non-existant IP address, then all of Ruby will block
> for about 20 seconds. I think that this is a result of a poor windows
> non-blocking socket implementation.

I'd guess it is due to differences in DNS-resolution.  Maybe there are
different timeouts effective on Windows and Linux / Solaris etc.

> One solution that I have thought of
> but not tried, would be to use blocking sockets on windows and do the
> operation within a native thread and then just signal back to the ruby
> thread when there is a result of the operation.

Akward.  But such things happens all too often in Windows Land... :-(

    robert