Re: signals and fhandlers

["Robert Collins" <robert dot collins at itdomain dot com dot au>]

----- Original Message -----
From: "egor duda" <deo@logos-m.ru>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin-developers@cygwin.com>
Sent: Friday, March 30, 2001 4:29 PM
Subject: Re: signals and fhandlers


> Hi!
>
> Friday, 30 March, 2001 Robert Collins robert.collins@itdomain.com.au
wrote:
>
> RC> I've finished the fifo support logic and code. (based on test
results
> RC> from openBSD for the expected behaviour).
>
> RC> I need to _guarantee_ that the close() routine for the fhandler
will get
> RC> called even if the process terminates due to a signal.
>
> the problem is that you cannot guarantee this.

Ok.

> RC> Is that automatically taken care of once I put the code in
cygwin1.dll
> RC> rather than as an external test program?
>
> if signal is normal unix-style signal that is sent from other cygwin
> application then everything's ok, close() will be called. but,
> unfortunately, process can be killed using native tools, such as task
> manager, and in this case process haven't got a chance to catch this
> and exit gracefully.
>
> so, instead of relying on close() being called, i'd rather agree with
> Chris' suggestion to use native anonymous pipe to implement fifo. in
> this case, all writers (or readers) will be notified when all readers
> (or writers) die by windows kernel, so process killed from task
> manager wouldn't pose a problem. this method will also support
> non-cygwin application which inherit fifo handle from cygwin ones. The

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!). As long as cygwin generated signals will allow
close() to be called I'm happy. The code I've got is really pretty
simple (simpler than the test I sent out), and there's no issue with
closed anon pipes not indicating they're closed.

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

> only problem with this method is the need to share write-side handle
> of fifo among all writers and read-side handle among all readers, and
> this will require the same thing that is used now in tty handling
> code -- removing process security protection to allow anybody to dup

Actually that's not the right way to do it. The correct way to do it is
build a security descriptor from the fifo disk file access permissions,
and then use that security descriptor when creating the handles. That
way no server process is needed. And it does allow different users, and
changed context users to access the handles.

> handles from it. or, instead, of removing security we can rely on
> special "cygwin daemon" process to do the handle dup()ing.

I still think the cygwin daemon is unneeded with appropriate security
descriptor creation. (see above).

>
> Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet
2:5020/496.19
>
>
>