[ruby-core:21850] Re: [Bug #738] Repeated calls to popen cause thread problems

2008/12/25 Tanaka Akira <[e-mail]>:
> In article <[e-mail]>,
>  Michal Suchanek <[e-mail]> writes:
>
>> Bug #738: Repeated calls to popen cause thread problems
>> http://redmine.ruby-lang.org/issues/show/738
>
>> Also there is a problem with the pipe one gets from
>> popen. Using the same IO in both threads is the only safe
>> way in MRI (although caution would advise to duplicate the
>> IO as shown in testt.rb). Duplicating the IO results in
>> deadlock error within about 200 calls in any recent MRI
>> Ruby I tried but is required in JRuby.
>
> "IO::for_fd analyzer.fileno" in testt.rb is dangerous.
> It makes two IO objects, X and Y, share single file
> descriptor N.
>
> When X is closed, N is closed.  Since Y refer N, Y doesn't
> work.
>
> However, Y doesn't know that N is closed.  Y still refer N.
>
> If the process opens a file, creates a pipe or whatever
> allocates a file descriptor, the allocated file descriptor
> may be N because N is closed.
>
> After that, operations on Y is done for the newly allocated
> file descriptor.  For example, if Y is closed, the new file
> descriptor is closed.
>
> So, don't duplicate IO as "IO::for_fd analyzer.fileno".
>
> I'm not sure why JRuby works well with that.
>
> Note that duplex IO.popen returns an IO object which have
> two file descriptors.  So the above description is not
> accurate.

Note that the descriptor is closed by the reading thread after it is
done with reading so the worst that can happen is that close_write
operates on a closed descriptor.

The exception from that should be catched with

fd.close_write rescue nil

The reading thread cannot finish before the writing thread because it
must get all the data that was written to finish.

Also the exception should be EBADF in case the descriptor is closed
while a thread still uses it.

Thanks

Michal