Pipes and signals with X puzzle

Pipes and signals with X puzzle

Post by Claudio Flein » Tue, 04 Apr 1995 04:00:00

>*3) The stdin pipe, up to the point when the interrupt was issued, but
>    no further has to be discarded WITHOUT EVER BLOCKING.

First, you can never count signals on a UNIX System, as they are by definition
not reliable (at least not if you don't use POSIX Signals). A second
problem is that if you interrupt your program while it executes
a syscall, the syscall may be interrupted and returns an error instead
of what it should have done (again, if and how this happens depends
on your UNIX and how you catch signals).

I would recommend the following (I assume that you want to keep
the pipes):

1. Use two pipes, one for normal use and one for emergency's.
2. Instead of sending an interrupt, write a special flag
   to BOTH pipes.
3. Read the emergency pipe regularly (maybe you want to use SIGIO to
   get a signal whenever there is something to read).
4. Whenever a character arrives on the emergency pipe, read the other
   pipe until you find the other emergency character.

Hope this helps,



International Computer Science Institute, 1947 Center Street, Berkeley
Tel: (510) 643-9153,   Fax: (510) 643-7684


Pipes and signals with X puzzle

Post by Carl Seghe » Tue, 11 Apr 1995 04:00:00

: *3) The stdin pipe, up to the point when the interrupt was issued, but
:     no further has to be discarded WITHOUT EVER BLOCKING.

: 1) and 2) are no problem. Number 3 is the tricky part. What I have
: tried is this:

: 1) A signal handler which just counts the signals received
: 2) When interrupting I raise the signal, AND write a special flag char
:    to the pipe.
: 3) The WorkProc counts how many flag chars it has seen, if there have
:    been more signals than flags, it reads (without blocking) the input
:    stream till the numbers balance.

The way I understand it is that you have two processes, one which
reads stdin and puts it on a pipe to the other one, the
X-program. When the first detects a special command, it wants to signal
the other process of this fact, whereupon the latter has to discard
its input up to the special command.

I suggest you use a synchronisation scheme:

let the input-parser be p, and the x-program be x.

When p detects a special command, it signals x and waits for
response. When x gets the signal, it clears out its input-pipe (by
reading it until it would block (*)), after which x notifies p it is
ready to accept the command (you can either have x send a signal to p,
or use another pipe (or use the same if it is full-duplex)). Now p
sends the command and continues its normal duties. x gets the command
and continues its normal duties.

This scheme is vulnerable to deadlock though, if the signals are
unreliable (like when using non-POSIX-compliant libraries). In that
case, in stead of having p wait for a sign from x, you can have p wait
until a read from the pipe would block (*) (**), which must eventually
happen, regardless of whether x got the signal or not.

*  you can test the status of the pipe without blocking with the
select(2) function.
** p must test the status of the pipe on the other end of where it
writes, ofcourse.

BTW in stead of having p just copy its stdin into the pipe, you can
make it do the full parsing of the input and only send the tokenized
command. This way the parsing of the input will be much easier for x.
No need for x to build up it's command: in stead of the workproc, you
can install an inputhandler on the pipe (XtAppAddInput), which is
fired only when there is input available (a full command). This too
requires reliable signals.

Hope this helps.

: Thanks!
: Alan.


Carl Seghers
TFP Engineering


1. Pipes and signals with X puzzle

I would have thought that this is the wrong way to go. There is some way
in Xt to add your own file descriptor to Xt's select() call. Shouldn't you
be doing this? Non blocking reads are usually a sign of a bad design. I
suspect that this will save you from mucking around with signals too.

If this doesn't work, you might try putting in your own Xt mainloop and
calling select(). This would mean you could give priority to commands
coming from stdin.

If you don't know how to do this I think the X FAQ mentions  it.

Chris Bitmead

2. Oh! What joy Linux is.

3. Signals and threads - still puzzling

4. Which flavour to install

5. Q: Puzzling Linux/OSF signal semantics

6. pop mail problem

7. signal puzzle

8. Windows NT nightmare story

9. Matrox Mystique ands X.

10. dump pipe gzip pipe ssh pipe dd... blocksize?

11. Stream, Pipes, Communication Domains, Signals ??

12. "XIO: broken pipe", can it be caught bye signal()?

13. When a pipe updated, any signal can be caught?