On Sat, 15 Aug 1998, Ted Rule wrote:
> As I understand it, the problem arises because the Linux Kernel refuses
> to let a process open a named pipe
> for writing, which is what the $monfifo pipe is, if no-one is reading
> it. The same applies in reverse.
I'm not sure this is quite correct unless you specify the state of several
options flags that are passed to the open() syscall, but in the case of
diald and the output FIFO this is exactly right. I remember this problem
from a year or more ago when I first subscribed to linux-diald - has dctrl
never been fixed in all that time? (I don't use dctrl myself)
I have used, on the few occasions I needed the monitor, the following
manual method to view the monitor output, never with any trouble at all.
>From one virtual console (usually a normal user - no need for root or
other special permissions here):
cat <diald.monitor
where diald.monitor is a FIFO in the user's login directory. This job
blocks waiting for data, of course. Then in another virtual console,
running as root, I just do
echo monitor ~user/diald.monitor >/var/run/diald.fifo
# /var/run/diald.fifo is where Debian 1.3 puts it
and voila, the process that was blocking in cat starts echoing the monitor
data. When I get tired of watching it, I just interrupt the cat'ing
process, it closes the FIFO, and diald stops sending data to the no longer
listened-to FIFO. This last is why diald wants to open the FIFO in a mode
that won't allow the open if there is no one listening. IIRC, the
discussion last time finally reached a consensus that this is how it must
be to avoid unlikely but possible race conditions.
> Whichever way you cut it, one process blocks awaiting the reader or
> writer - whoever came first.
The way the diald side of it works, it MUST be the reader who blocks,
waiting for diald to start sending data. Otherwise you got trouble.
> I believe Walter's "de-patch" makes diald potentially block on dctrl's
> behaviour - which is surely unhealthy...
I think you're right, though I didn't examine the earlier patches in any
detail - it was a busy time for me and I let it slide, thinking that
surely someone else would recall the previous discussion.
> My fix is to open the pipe non-blocking for read BEFORE requesting that
> diald open it for writing.
> Then ask diald to write to the pipe. Then open a second file-descriptor
> on the pipe blocking for read.
> Then close the original descriptor. And finally register events on the
> blocking descriptor.
I guess that will work. I think the proper way to go about this is to use
two processes, one of which opens the FIFO and blocks waiting for data
before the other sends the "monitor ..." command to diald. But if you're
trying to avoid forking off a relatively heavyweight Perl process then the
open-twice approach might be okay. I think you have a potential problem
with having two readers contending for the data (only briefly, but still),
but if you prefer to work around that rather than using the usual Unix
idiom for this sort of thing (fork), that should be safe enough.
> sanity. In particular, we have a smidgen of time during which there are
> two readers on the pipe.
> This is probably very dangerous... but it needs a kernel guru to tell us
> all the legality of the situation.
I Am Not A Guru, but I think the danger is no worse than that two readers
are contending.... uhm, wait, are they? There aren't actually two readers
there, just two opens of the same data stream. Sometimes I'm very gald
that I Am Not A Guru! :-)
> The question is.. if diald chooses to write to the pipe whilst there are
> two readers - neither of which have
> issued a read call... is it a gamble as to which of the two readers gets
> the data? Or will the data always be delivered to the first file
> descriptor to read the pipe.
I believe it should go to the first to issue a read, especially since only
one will ever do so. But I Am NOT A Guru (and I'm too lazy this afternoon
to try to dig up an authoritative answer).
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
