* named pipes blocking zsh
@ 2005-06-01 14:18 Tim K. (Gmane)
2005-06-01 14:47 ` Bart Schaefer
2005-06-01 14:47 ` Peter Stephenson
0 siblings, 2 replies; 7+ messages in thread
From: Tim K. (Gmane) @ 2005-06-01 14:18 UTC (permalink / raw)
To: zsh-users
Hello,
I have a situtation with zsh: I use pine as my mail reader and it has a
feature where it can create a named pipe (FIFO) and write to it when new
mail arrives. Naturally, I thought of writing a script at the other end
of the pipe that reads the messages and sends me notifications in some
other way.
The way I have it set up is to have a zsh script that starts another
"notify" child zsh script that reads from the pipe and does its
notification thing and then the main script calls pine.
This all seems to work, except when I quit pine, hence terminating the
main "parent" script, the child "notify" script does not exit, it's
stuck reading from the pipe (even though the pipe is deleted). The child
script becomes owned by PPID 1 and the only way to kill it is kill -9 ...
I'm reading with the built in "read var < pine_pipe" which blocks until
the first line of data is written to the pipe by pine. I also tried
"read -t" but it doesn't react to the timeout. Also tried the zselect
module, with and without timeouts, nothing works. If there's nothing in
the pipe, the zsh process just hangs until there is data.
My current workaround is to trap the exits from the main script and kill
-9 the child script. This works fine almost all the time except when the
main script itself is killed and it doesn't have a chance to kill it's
child. For this I made the notify script clean up any running instances
of itself when it comes up (but there's still that window of time where
there's a zsh process around that refuses to die).
Is there anything in particular I should be aware of with these named
pipes? I'm using zsh 4.2.1 if it makes a difference ...
Thanks for your help.
--
Tim
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: named pipes blocking zsh
2005-06-01 14:18 named pipes blocking zsh Tim K. (Gmane)
@ 2005-06-01 14:47 ` Bart Schaefer
2005-06-01 15:20 ` Tim K. (Gmane)
2005-06-01 15:24 ` Tim K. (Gmane)
2005-06-01 14:47 ` Peter Stephenson
1 sibling, 2 replies; 7+ messages in thread
From: Bart Schaefer @ 2005-06-01 14:47 UTC (permalink / raw)
To: zsh-users
On Jun 1, 7:18am, Tim K. (Gmane) wrote:
}
} I have a situtation with zsh: I use pine as my mail reader and it has a
} feature where it can create a named pipe (FIFO) and write to it when new
} mail arrives.
}
} This all seems to work, except when I quit pine, hence terminating the
} main "parent" script, the child "notify" script does not exit, it's
} stuck reading from the pipe (even though the pipe is deleted).
I think this qualifies as a pine bug. Removing a named pipe will not
by itself send an EOF to any processes that are listening on it. The
right way for pine to shut down the connection would be to open the fifo,
remove the disk file, then send a final EOF by closing the descriptor.
Anything else is a race condition with the listening process, which may
re-open the fifo for reading before pine has removed it.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: named pipes blocking zsh
2005-06-01 14:18 named pipes blocking zsh Tim K. (Gmane)
2005-06-01 14:47 ` Bart Schaefer
@ 2005-06-01 14:47 ` Peter Stephenson
1 sibling, 0 replies; 7+ messages in thread
From: Peter Stephenson @ 2005-06-01 14:47 UTC (permalink / raw)
To: zsh-users
"Tim K. (Gmane)" wrote:
> I have a situtation with zsh: I use pine as my mail reader and it has a
> feature where it can create a named pipe (FIFO) and write to it when new
> mail arrives. Naturally, I thought of writing a script at the other end
> of the pipe that reads the messages and sends me notifications in some
> other way.
>
> The way I have it set up is to have a zsh script that starts another
> "notify" child zsh script that reads from the pipe and does its
> notification thing and then the main script calls pine.
>
> This all seems to work, except when I quit pine, hence terminating the
> main "parent" script, the child "notify" script does not exit, it's
> stuck reading from the pipe (even though the pipe is deleted). The child
> script becomes owned by PPID 1 and the only way to kill it is kill -9 ...
>
> I'm reading with the built in "read var < pine_pipe" which blocks until
> the first line of data is written to the pipe by pine. I also tried
> "read -t" but it doesn't react to the timeout. Also tried the zselect
> module, with and without timeouts, nothing works. If there's nothing in
> the pipe, the zsh process just hangs until there is data.
I'm not sure how much the shell can do about this...
The shell is actually blocking in the "open" call to pine_pipe, not in
the builtin itself. This is the way reading from pipes works: you can't
open the pipe until someone is writing to it. If the open fails, it's up
to the system to tell the shell, which will find out as soon as the call
returns, and can't very well find out it before.
It's possible to open without blocking, but that's not actually what you
want: you need to blocking behaviour to be able to open the pipe when
the other side writes to it.
I can't offhand think of a simple solution.
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: named pipes blocking zsh
2005-06-01 14:47 ` Bart Schaefer
@ 2005-06-01 15:20 ` Tim K. (Gmane)
2005-06-01 15:36 ` Peter Stephenson
2005-06-01 15:45 ` Bart Schaefer
2005-06-01 15:24 ` Tim K. (Gmane)
1 sibling, 2 replies; 7+ messages in thread
From: Tim K. (Gmane) @ 2005-06-01 15:20 UTC (permalink / raw)
To: zsh-users
What's interesting is that if I 'strace' the zsh process while it's
stuck (after the pipe was deleted), it will terminate. I'm not sure what
the explanation behind it is ...
Thanks.
Tim
Bart Schaefer wrote:
>On Jun 1, 7:18am, Tim K. (Gmane) wrote:
>}
>} I have a situtation with zsh: I use pine as my mail reader and it has a
>} feature where it can create a named pipe (FIFO) and write to it when new
>} mail arrives.
>}
>} This all seems to work, except when I quit pine, hence terminating the
>} main "parent" script, the child "notify" script does not exit, it's
>} stuck reading from the pipe (even though the pipe is deleted).
>
>I think this qualifies as a pine bug. Removing a named pipe will not
>by itself send an EOF to any processes that are listening on it. The
>right way for pine to shut down the connection would be to open the fifo,
>remove the disk file, then send a final EOF by closing the descriptor.
>
>Anything else is a race condition with the listening process, which may
>re-open the fifo for reading before pine has removed it.
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: named pipes blocking zsh
2005-06-01 14:47 ` Bart Schaefer
2005-06-01 15:20 ` Tim K. (Gmane)
@ 2005-06-01 15:24 ` Tim K. (Gmane)
1 sibling, 0 replies; 7+ messages in thread
From: Tim K. (Gmane) @ 2005-06-01 15:24 UTC (permalink / raw)
To: zsh-users
Now that I think about it, what if the pine process crashed and didn't
have a chance to send an EOF or remove the pipe (assuming pine
implemented the EOF)? It seems that the read with timeout in zsh should
work, it should not just block forever even though a timeout is
specified, but maybe it's not possible to do because it's stuck in
open() not in a read call.
Thanks.
>
>I think this qualifies as a pine bug. Removing a named pipe will not
>by itself send an EOF to any processes that are listening on it. The
>right way for pine to shut down the connection would be to open the fifo,
>remove the disk file, then send a final EOF by closing the descriptor.
>
>Anything else is a race condition with the listening process, which may
>re-open the fifo for reading before pine has removed it.
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: named pipes blocking zsh
2005-06-01 15:20 ` Tim K. (Gmane)
@ 2005-06-01 15:36 ` Peter Stephenson
2005-06-01 15:45 ` Bart Schaefer
1 sibling, 0 replies; 7+ messages in thread
From: Peter Stephenson @ 2005-06-01 15:36 UTC (permalink / raw)
To: zsh-users
"Tim K. (Gmane)" wrote:
> What's interesting is that if I 'strace' the zsh process while it's
> stuck (after the pipe was deleted), it will terminate. I'm not sure what
> the explanation behind it is ...
Presumably to be able to trace the system call there is a different
pathway through the open() call.
pws
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: named pipes blocking zsh
2005-06-01 15:20 ` Tim K. (Gmane)
2005-06-01 15:36 ` Peter Stephenson
@ 2005-06-01 15:45 ` Bart Schaefer
1 sibling, 0 replies; 7+ messages in thread
From: Bart Schaefer @ 2005-06-01 15:45 UTC (permalink / raw)
To: zsh-users
On Jun 1, 8:24am, Tim K. (Gmane) wrote:
}
} Now that I think about it, what if the pine process crashed and
} didn't have a chance to send an EOF or remove the pipe (assuming pine
} implemented the EOF)?
A crash that severe is by definition an unrecoverable error; it's not
possible to write code to handle it, and it's certainly not zsh's job
to attempt to handle unrecoverable errors in other arbitrary programs.
On Jun 1, 8:20am, Tim K. (Gmane) wrote:
} Subject: Re: named pipes blocking zsh
}
} What's interesting is that if I 'strace' the zsh process while it's
} stuck (after the pipe was deleted), it will terminate.
That's almost certainly because strace sends a SIGPROF to zsh, which
interrupts whatever system call was blocking on the fifo.
I suspect that if you attempted something other than "kill -9" (such as,
say, "kill -1") you'd find that it *is* possible to politely interrupt
zsh when it's waiting on the fifo.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-06-01 15:49 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-01 14:18 named pipes blocking zsh Tim K. (Gmane)
2005-06-01 14:47 ` Bart Schaefer
2005-06-01 15:20 ` Tim K. (Gmane)
2005-06-01 15:36 ` Peter Stephenson
2005-06-01 15:45 ` Bart Schaefer
2005-06-01 15:24 ` Tim K. (Gmane)
2005-06-01 14:47 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).