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: a couple proposed patches


On Fri, May 09, 2003 at 11:22:51AM -0400, Joe Buehler wrote:
>PATCH 1 -- a patch that eliminates the need for TerminateThread() when
>reading pipes.  A read() on a pipe starts a thread, but it is left
>running in the background if a signal happens before the read
>finishes.  It works fine, but there are a couple things that need
>to be cleaned up that will be easier with your knowledge of the
>Cygwin internals.

How could this possibly work?  You get a signal, keep reading, and
then another process which also has the pipe open wants to grab data from
the pipe.  But, it can't get it because the original process has sucked
it all in.  So you store the data in shared memory?  And have to worry
about who gets what data when?  Ugh.  That wouldn't work with native
windows apps anyway.

>PATCH 2 -- a patch to make strace output go directly to a memory-mapped
>file, with very minimal inter-thread interference (one call to
>InterlockedAdd() is the only "locking").

Um, this is close to the way that strace used to work.  No, I'm sorry, but
I'm not interested in either of these.

I am very interested in not rediscussing the pipe issues though.  The
ground rules are that pipes have to continue to work with other
processes whether they are native windows or cygwin processes.  They
must be actual windows handles, not special cygwin constructs.  If you
have a scenario which satisifies these requirements then please outline
how it will work when you propose something.

cgf


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