[ruby-talk:21623] Re: opening a named pipe?

On Unix, opening a FIFO will block the process until the other end is also
opened.  So opening the FIFO to read before starting the writer process will
cause a deadlock.

Change the code to:

sendCmdToDiald( 'monitor', $STATUS_FIFO_NAME )
File.open($STATUS_FIFO_NAME,'r') do |status_fifo|
    # read from FIFO
end

There are advantages to Ruby's lightweight threads.  One advantage is that
you get exceptions thrown when deadlock occurs between threads.  Another
advantage is that they are cheap -- you can create lots of threads without a
lot of overhead, which is not possible with OS threads.


----- Original Message -----
From: "Avdi B. Grimm" <[e-mail]>
To: "ruby-talk ML" <[e-mail]>
Sent: Monday, September 24, 2001 4:18 AM
Subject: [ruby-talk:21616] opening a named pipe?


> I'm having trouble reading from a named pipe in linux. basicly, I'm
> creating a pipe for another program (diald) to write status information
> to, opening the pipe, and then telling the external program to start
> writing to the named pipe. A simplified version of the code follows:
>
> `mkfifo #{$STATUS_FIFO_NAME}`
> File.open($STATUS_FIFO_NAME, 'r') {|status_fifo|
>   sendCmdToDiald 'monitor', $STATUS_FIFO_NAME
>   timeout(2.0) {  # ensure this doesn't read indefinitely
>     # ... read and store data from the pipe
>   }
> }
>
> Except on rare occasions, this code never gets past the call to
> File#open. It just hangs on the open indefinitely. I can't even put a
> timeout on the 'open' call; presumably because it's an IO issue and Ruby
> threads all halt for IO.  Every now and then, with no predictability,
> the code works perfectly, but it usually hangs.
>
> 1. Can anyone tell me what I'm doing wrong?
>
> 2. Has anyone created a Ruby wrapper for mkfifo or any of the other more
> obscure *NIX calls? 'ftools' seems to only contain cross-platform file
> commands.
>
> 3. Is anyone working on native threads for Ruby yet?  Having threads
> that may block unpredictably is incredibly annoying for someone used to
> coding fully-multithreaded apps in C++. Couldn't we just wrap the
> excellent ACE middleware? No need to reinvent the wheel...
>
>