Cygwin: FIFO: update commentary
This commit is contained in:
parent
3b5711c008
commit
9b7cda2ca1
|
@ -52,10 +52,23 @@
|
||||||
which is mostly idle. The thread wakes up if that reader might
|
which is mostly idle. The thread wakes up if that reader might
|
||||||
need to take ownership.
|
need to take ownership.
|
||||||
|
|
||||||
There is a block of shared memory, accessible to all readers,
|
There is a block of named shared memory, accessible to all
|
||||||
that contains information needed for the owner change process.
|
fhandlers for a given FIFO. It keeps track of the number of open
|
||||||
It also contains some locks to prevent races and deadlocks
|
readers and writers; it contains information needed for the owner
|
||||||
between the various threads.
|
change process; and it contains some locks to prevent races and
|
||||||
|
deadlocks between the various threads.
|
||||||
|
|
||||||
|
The shared memory is created by the first reader to open the
|
||||||
|
FIFO. It is opened by subsequent readers and by all writers. It
|
||||||
|
is destroyed by Windows when the last handle to it is closed.
|
||||||
|
|
||||||
|
If a handle to it somehow remains open after all processes
|
||||||
|
holding file descriptors to the FIFO have closed, the shared
|
||||||
|
memory can persist and be reused with stale data by the next
|
||||||
|
process that opens the FIFO. So far I've seen this happen only
|
||||||
|
as a result of a bug in the code, but there are some debug_printf
|
||||||
|
statements in fhandler_fifo::open to help detect this if it
|
||||||
|
happens again.
|
||||||
|
|
||||||
At this writing, I know of only one application (Midnight
|
At this writing, I know of only one application (Midnight
|
||||||
Commander when running under tcsh) that *explicitly* opens two
|
Commander when running under tcsh) that *explicitly* opens two
|
||||||
|
|
Loading…
Reference in New Issue