RE: FIFOs again

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

> >
> > The second thing is a killer, at least without a rethink.
> In the case
> > first shown, where the fifo is never opened, but this time
> does still
> > exist, the zsh just hangs on for ever waiting for it and sits around
> > uselessly in the process table.
>
>
> Yes, I got the same. Real nasty. One possibility is "dummy open" in
> parent. The child hangs because it tries to open FIFO without
> counterpart. Parent can simply open it and then close when child exits
> or we're done with current commmand (it currently have to delete FIFO
> anyway).
>

Actually, it seems to be possible to immediately close it. The following
trivial change to getproc() (marked with >>>>>>) seems to do the trick
(no more hung processes).

#ifndef PATH_DEV_FD
    if (!jobtab[thisjob].filelist)
 jobtab[thisjob].filelist = znewlinklist();
    zaddlinknode(jobtab[thisjob].filelist, ztrdup(pnam));

    if (zfork()) {
>>>>>> dummy = open(pnam, !out ? O_WRONLY | O_NOCTTY : O_RDONLY |
O_NOCTTY);
>>>>>> close (dummy);
#else
    mpipe(pipes);
    if (zfork()) {
 sprintf(pnam, "%s/%d", PATH_DEV_FD, pipes[!out]);
 zclose(pipes[out]);
 fdtable[pipes[!out]] = 2;
#endif
 return pnam;
    }

This looks safe - we do it only if fork() was successful and then child
will open FIFO in turn. BTW this is also a way to sync child and parent
to some extent. Oh, yes, and it should fix the first mentioned problem -
that parent removes FIFO too early.

-andrej