Cygwin: FIFO: update commentary

This commit is contained in:
Ken Brown 2020-07-11 15:43:44 -04:00
parent f56dc33579
commit ac371ee1ba
1 changed files with 17 additions and 4 deletions

View File

@ -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