Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com Date: Thu, 17 May 2001 18:27:34 -0400 Message-Id: <200105172227.SAA23422@envy.delorie.com> X-Authentication-Warning: envy.delorie.com: dj set sender to dj AT envy DOT delorie DOT com using -f From: DJ Delorie To: robert DOT collins AT itdomain DOT com DOT au CC: cygwin-developers AT cygwin DOT com In-reply-to: <019501c0df1f$c3dffaf0$0200a8c0@lifelesswks> (robert DOT collins AT itdomain DOT com DOT au) Subject: Re: [cgf AT redhat DOT com: fhandler redesign] References: <20010517164155 DOT A25918 AT redhat DOT com> <200105172101 DOT RAA22405 AT envy DOT delorie DOT com> <019501c0df1f$c3dffaf0$0200a8c0 AT lifelesswks> > > 1. The physical device/file. Two programs could be writing to > > different parts or instances of the device simultaneously. I think > > NT takes care of this for us, but virtual devices we create we'd > > need to think about this. I can't think of examples, though, so we > > can probably leave it up to the #2 layer to figure out how/where to > > deal with this, rather than have it as an explicit layer. > > FIFO's come to mind. The clipboard is potentially in this case as well. Right, but in both of those cases, the details at this layer can be safely hidden deep within the driver's DLL.