Mail Archives: cygwin-developers/2001/03/30/01:32:50
Hi!
Friday, 30 March, 2001 Robert Collins robert DOT collins AT itdomain DOT com DOT 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.
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
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
handles from it. or, instead, of removing security we can rely on
special "cygwin daemon" process to do the handle dup()ing.
Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
- Raw text -