pipe replacement w/o TerminateThread

Joe Buehler jbuehler@hekimian.com
Tue Apr 15 21:21:00 GMT 2003

Steve O wrote:

> How about encapsulating windows processes in a shell that converts
> cygwin pipes to windows handles?  Nearly everything I run from a 
> shell in windows is a cygwin app.  The rest launch their own windows
> and don't expect input from stdin or print to stdout.   So, having
> some crazy overhead to launch a rare windows console app wouldn't be 
> a big loss, compared to the win of having robust ttys and pipes.
> Taking it further, perhaps a lot of the fork weirdness could be stuffed
> into the windows 'special case' shell. 

Christopher's comments got me thinking about something like this:

Use standard anonymous pipes between processes, but put an interruptible
front-end on it when inside a Cygwin process.

A Windows process would be happy because it has a pipe, and the Cygwin
process would be happy because its read() and write() calls can be

Implementation-wise, this might actually be similar to the current
implementation: another thread to do the blocking reading/writing
so the main thread can be interrupted.  But don't terminate the
reader/writer thread when a read or write is interrupted, let it keep running,
doing the appropriate thing depending on whether the main thread
is waiting for data or off doing something else.  If it gets data
from the other end of the pipe, put it in a buffer and wait for
the main thread to come get it before going to read more.  If it
finishes writing data to the pipe, let it go back and wait for more
from the main thread.  The front-end can buffer internally if this
benefits performance.

One problem: Is there a way to tell that a handle is a pipe?  If a
Cygwin process inherits a pipe on stdin (say) from a windows process,
there needs to be a way to tell that it's a pipe.
Joe Buehler

More information about the Cygwin-developers mailing list