Very Computer

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,

Claudio

--
----------------------------------------------------------------------

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

: *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.

Cheers,
Carl

--
Carl Seghers
TFP Engineering