: *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
** p must test the status of the pipe on the other end of where it
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.