Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Date: Mon, 18 Sep 2000 20:06:57 +0400
From: Egor Duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: Egor Duda <cygwin-developers AT sources DOT redhat DOT com>
Organization: DEO
X-Priority: 3 (Normal)
Message-ID: <383566892.20000918200657@logos-m.ru>
To: cygwin-developers AT sources DOT redhat DOT com
Subject: Re: mkfifo for cygwin
In-reply-To: <39C4B074.7BB3BFB4@cygnus.com>
References: <Pine DOT LNX DOT 4 DOT 10 DOT 10009131121310 DOT 383-100000 AT bono DOT reversers DOT net>
 <39BFE130 DOT 7C02C8AA AT cygnus DOT com> <174366362581 DOT 20000916181450 AT logos-m DOT ru>
 <39C4B074 DOT 7BB3BFB4 AT cygnus DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

Sunday, 17 September, 2000 Corinna Vinschen vinschen AT cygnus DOT 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 AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19