On Mon, 2001-09-24 at 05:14, Nat Pryce wrote:
> Change the code to:
> 
> sendCmdToDiald( 'monitor', $STATUS_FIFO_NAME )
> File.open($STATUS_FIFO_NAME,'r') do |status_fifo|
>     # read from FIFO
> end

Nope, tried that.  Diald doesn't like it when there's no one reading on
the other end... it only starts writing if another process has *already*
opened the pipe for read when it gets the command to start writing.
I've confirmed this with tests on the command line, manually creating
pipes and telling Diald to write to them.  If I have a 'cat' command
pending on a pipe, and then tell diald to write to that pipe, it works
and the 'cat' command starts displaying the diald output.  But if I tell
diald to start writing, and then start 'cat /tmp/myfifo', (where
/tmp/myfifo is a fifo I've already created with mkfifo) then diald
complains: "could not open pipe /tmp/myfifo: No such device or address".


> 
> 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.

I was under the impression that was the whole point of OS threads...
that they were far lighter weight than processes, on OSs that supported
them well.  I work in the embedded systems field, which is utterly
dependant on pervasive multithreading... fork&execing on such systems
would be prohibitively expensive, but it's quite common to use dozens of
threads, and this sometimes on processors with very tight memory and
performance constraints.  Is there evidence that Ruby threads incur
*substantially* less overhead than native threads on an OS which was
built with threading in mind?

~Avdi