This is the mail archive of the cygwin-developers@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: mkfifo for cygwin


Hi!

Sunday, 17 September, 2000 Corinna Vinschen vinschen@cygnus.com wrote:

perhaps it's better to discuss it here.

CV> Nothing specific. I was quite motivated to use NT named pipes
CV> when Chris demands that the solution should work on 9X.
CV> On the other hand I had enough to do so I only thought about
CV> the problem from time to time with different disadvantages in
CV> mind. As result, I delayed the decision...

>> 1. it's not clear, which "carrier" we should use -- named pipes are nt
>> only, shared memory is not secure enough (no write-only mode)
>> moreover,  named  pipes should be opened and closed on each read/write
>> operation,  otherwise  i don't know how to handle multiple readers <=>
>> multiple  writers.  Creating pipes anew for every fifo operation looks
>> pretty  expensive.  So,  personally, i prefer shared memory region.

CV> Yes, unfortunately named pipes on NT are quite different from UNIX.

CV> What about sort of UDP listener?

tcp/ip  is  not  always  installed.  even  if  host  do participate in
network,  it  can  use  transports  other  then  ip.  ipx for example.
or host may have no network installed at all.

>> frankly, i don't care much about w9x, but of course it would be better
>> to support w9x too.

CV> Yeah, me too. Personally, I don't have any problems with features
CV> not working on 9X/ME. But I can understand Chris here.

I'm thinking of the following scheme now:

- Shared memory buffer: (buffer_for_data, head_pointer, tail_pointer)
- "current  writer"  mutex:  thread which owns this mutex is supposed to
  write data to buffer when there will be free space in it.
- "current  reader"  mutex:  thread which owns this mutex is supposed to
  read data from buffer when data is available.
-   "data  available"  and  "free  space  available"  events: to wake
  current writer and reader.
-  "writers available" event: to notify readers that they can "attach"
  to fifo.
-  File  to  asynchronously  notify readers when all writers exit/die.
  Each  writer  open  this file an issues LockFile on his own separate
  1-byte-long   region.   Each  reader  calls LockFileEx on whole file
  in OVERLAPPED mode. then overlapped event will be signalled when all
  writers exit/die. (this part is the one which won't work under w9x).

then write() in writer thread will wait for "current writer" mutex and
after  acquiring  it'll wait for "free space available" event. then it
write data, and post "data available event". if buffer is full it will
reset "free space available" event.

read() in reader thread will wait for "current reader" mutex, then
wait  for  "overlapped lock" event and "data available" event. in case
of  "data  available"  it'll read data and post "free space available"
event. if all data is read then reader reset "data available" event.
in  case  of  "overlapped  lock"  event, reader thread will go int eof
state and free all fifo-assisiated resources.

If  someone have any thoughts of how to avoid LockFileEx then probably
it would be possible to support w9x too.

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]