From: Michael Malone <michael.malone@...>
Date: 2009-03-16T08:17:47+09:00
Subject: Re: does IO.read block?

Robert Klemme wrote:
>> rescue Exception => error
>>   ex_string = Marshal.dump(error)
>>   ex_size = ex_string.bytesize
>>   bytes_written = 0
>>   while bytes_written < ex_size
>>     bytes_written += write_end.write(ex_string.slice!(bytes_written))
>>   end
>>   ensure
>>     write_end.close
>
> You do not seem to open the stream in this context, why do you close 
> it here?  Or do you have a pattern like
that code is inside the block passed to fork(), so the write_end needs 
to be closed so the parent process reads an EOF.  The pipe is opened 
prior to the fork() call, so the fd should be copied to the child 
process, thus the parent process would block indefinitely waiting for 
the EOF.
> IMHO you can simplify that do
>
> rescue Exception => error
>   Marshal.dump(error, write_end)
> end
>
> Which should also be more efficient since the looping is done in C code.
Thanks, I've applied that.
> But again, I would just do
>
> obj = Marshal.read(read_end)
>
> Which, again is more efficient since you do not need the additional 
> buffer and looping is done in C code.
I need the additional buffer because an exception is not always thrown 
so attempting to unmarshal an empty string causes problems
> I am not sure what you mean by "rescheduled".  Even if the OS preempts 
> execution of this process or thread it will continue at the same 
> location of the stream and semantics of the methods do not change.
Yes, I meant preempted.
>
> Kind regards
>
>     robert

My problem still exists. :( I didn't get into the details of the 
specifics because I haven't proved where it exists.  I just got excited 
when I saw that as a potential problem area and figured it needed fixing 
because it would bite me sooner or later.

Back to the drawing board until I have a better question...

Thanks,
Michael


=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================