This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pipe replacement w/o TerminateThread


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
interrupted.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]