El Jueves, 7 de Enero de 2010, Robert Klemme escribi
> On 01/07/2010 06:58 PM, Iki Baz Castillo wrote:
> > El Jueves, 7 de Enero de 2010, Iki Baz Castillo escribi
> >> The doubt I have now is about how secure is a pipe.
> >> Could it leak memory if some process die or the reader process is not so
> >>  fast  to handle the received data?
> >
> > Hummm, I have a reader process and a writer process.
> 
> I thought you have multiple writers.  Didn't you mention multiple forked
> Rack handlers?

Yes, that's true. Sure I'll get into problems when writting in the FIFO from 
varios clients at the same time :)
But for that I could generate so many fifo's as Rack workers...



> > The wirter process writes into the pipe file.
> > If I kill the reader process then the writer process remains writting in
> > the pipe and the data is stored (in the filesystem?).
> >
> > So there is the leaking problem...
> 
> Not exactly: the writer is blocked.  You can try this out:
> 
> robert@fussel:~$ mkfifo ff
> robert@fussel:~$ ls -lF ff
> prw-r--r-- 1 robert robert 0 2010-01-07 19:25 ff|
> robert@fussel:~$ ruby19 -e 'puts("+"*10_000)' > ff
> ^Z
> [1]+  Stopped                 ruby19 -e 'puts("+"*10_000)' > ff
> robert@fussel:~$ wc ff &
> [2] 14036
> robert@fussel:~$ %1
> ruby19 -e 'puts("+"*10_000)' > ff
> robert@fussel:~$       1       1   10001 ff
> 
> [2]+  Done                    wc ff
> robert@fussel:~$ jobs
> robert@fussel:~$
> 
> At the point where I pressed Ctrl-Z the writer hung because the pipe was
> full.  (The size of a pipe is usually the memory page size of the OS
> IIRC, this would be 4k in case of Linux 32 bit).
> 
> > I must investigate it a bit more...
> 
> I'd personally prefer to use the DRb approach because then you can
> actually send typed messages, i.e. whatever information you need.  Also,
> it was fun to play around with those small test programs. ;-)  And you
> can have the reader run on any machine in the network.
> 
> Whatever you do, you have to decide how to go about the situation when
> the reader goes away - for whatever reasons.

It's realtime info so if the reader dies then it's not so important to recover 
that information when starting again. Well, it would be nice to recover it 
just for 5-10 minutes, but no more.



> You could write your
> messages to a file and use an approach like "tail -f" uses to read them.
>   But this has the nasty effect of clobbering the file system plus if
> the reader goes away the file might grow arbitrary large.  And you have
> locking issues.  Using any in memory pipe (e.g. mkfifo or via DRb) is
> preferrable IMHO.  The you can still decide in the client what you do if
> you cannot get rid of the message.

Yes, I must think a bit aobut it :)

Thanks a lot for your help.


-- 
Iki Baz Castillo <ibc / aliax.net>