>>   #=> not finished in 10 seconds  [ruby-dev:32566]
>> FAIL 1/918 tests failed
>> make: *** [btest-ruby] Error 1

Looks like the problem is that if you have two threads writing to the
same ruby file descriptor, there are some notes in io.c io_fflush
saying "other threads may modify wbuf--A lock is required, definitely"
-- i.e. a TODO note.

currently
thread 1 puts its string in the buffer, calls io_fflush.  io_fflush
calls write on its string.
thread 2 adds its string to the end of the buffer, calls io_fflush
which calls write on the entire buffer [which is now twice as large
and causes it to re-write the first thread's string]

thread 1 then returns from its write call, and discovers it has only
written half of what is currently in the buffer.  It therefore calls
write again for the rest of the buffer.

So I guess you could say that Ruby's internal buffering is not thread
safe--at least as used in io_fflush.

Possible ways to avoid this:
* have a mutex per descriptor in io_fflush [?]

* if there is more than one thread then don't do any
buffering--problem with this is that how do you go back and forth in a
thread safe way from using and not using the buffers, as you start and
stop threads.

* have io_fflush not actually flush "all"--problematic to synchronize
the flushing among threads, however.

* Add another entry to rb_io_t meaning "where I am writing within the
current buffer" -- but this is a problem because what if a first write
only half-succeeds and a second concurrent write also
half-succeeds--the string will have been written out of order.

* Maybe add an entry to rb_io_t meaning "is being flushed" -- but I
suppose that's like a mutex without the benefit of "instantaneous
wakeup" that pthread mutexes provide.

Does ruby have an OS agnostic mutex system [like macros]?

Thoughts?
Thanks.
-=R

On Wed, Oct 29, 2008 at 11:11 AM, Roger Pack
<roger.pack / leadmediapartners.com> wrote:
>
> Fascinating.  I get this "sometimes" too-- OS X.
> I did some research into it and it appears that "some functions"
> (possibly all non blocking region functions?) within a child thread
> execute twice