This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: signals and fhandlers
----- Original Message -----
From: "Christopher Faylor" <cgf@redhat.com>
To: "egor duda" <cygwin-developers@cygwin.com>
Sent: Saturday, March 31, 2001 1:44 AM
Subject: Re: signals and fhandlers
> On Fri, Mar 30, 2001 at 04:48:23PM +1000, Robert Collins wrote:
> >Chris's comment on inherited handles was that non-cygwin applications
> >don't know what to do _anyway_ with inherited handles. (Chris: maybe
I
> >got this wrong? ). Anyway the worst case is that the writers will not
> >know that the readers have all died and won't return EPIPE. This can
> >happen with things are killed via task manager anyway. (That's why
> >there's a warning!).
>
> That's the worst case that Egor was mentioning. If we can develop
> a scenario that allows the right thing to happen when a program takes
> a non-standard exit then we should pursue this at all costs. I have
> always tried to do this in all of my cygwin development. I have, so
> far, avoided relying on cygwin cleanups for proper operations.
Referencing
http://msdn.microsoft.com/library/psdk/winbase/prothred_1bg3.htm all
process handles are closed on a TerminateProcess() call. I'll see if I
can build detection of readers around some handle rather than a counter
as I have today. That'll give an accurate count even if the process is
terminated.
> >Also, the pipes will have to be in the cygwin shared memory area, and
> >Chris indicated he didn't want any more data in there (I was going to
> >try anon pipes, when I posted my question and got that answer)..
>
> I just said that you shouldn't use the existing shared memory areas.
You
> can create your own small shared memory areas.
>
That's what I took it to mean. In fact I am using named objects for my
implementation.
Rob