Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA09545; Thu, 22 Feb 96 14:55:51 EST Received: from fubar.cs.montana.edu by MIT.EDU with SMTP id AA14722; Thu, 22 Feb 96 14:55:29 EST Received: by cs.montana.edu; id AA27131; Thu, 22 Feb 1996 12:55:53 -0700 Date: Thu, 22 Feb 1996 12:55:53 -0700 From: Mail Delivery Subsystem Subject: Returned mail: Service unavailable Message-Id: <9602221955.AA27131@cs.montana.edu> To: proven@MIT.EDU ----- Transcript of session follows ----- binmail: opening /usr/spool/mail/lancer -: Permission denied Mail saved in dead.letter 554 ... Service unavailable ----- Unsent message follows ----- Received: by cs.montana.edu; id AA27068; Thu, 22 Feb 1996 12:55:53 -0700 Received: from YAZ-PISTACHIO.MIT.EDU by MIT.EDU with SMTP id AA22959; Thu, 22 Feb 96 14:00:51 EST Received: by yaz-pistachio.MIT.EDU (5.57/4.7) id AA05429; Thu, 22 Feb 96 14:01:19 -0500 Message-Id: <9602221901.AA05429@yaz-pistachio.MIT.EDU> To: Todd Enersen Cc: pthreads@MIT.EDU Subject: Re: pthreads, read() and linux In-Reply-To: Your message of "Wed, 21 Feb 1996 17:38:47 PST." Date: Thu, 22 Feb 1996 14:01:17 EST From: Christopher Provenzano > > I've written a device driver under Linux 1.[23].X that doesn't seem to be > Pthreads combatible. Basically, one thread is reading from the device > driver and posting events to a second thread, which is dealing with said > events. The read() in the first thread basically causes the second > thread from executing, since it is a blocking read(). > > My question is: Must all calls to read() be non-blocking in a Pthread > environment? And if so, does the standard C library handle this by > wrapping the read() and open() calls with ones that enforce a > non-blocking paradigm? So long as the driver supports non-blocking I/O, a thread may do a blocking read() and the thread engine (called from the read() wrapper routine) will ensure that only the thread is blocked. If the driver does not support non-blocking I/O then the right thing won't happen until I add support for kernel threads (using the clone() call provided). Basicly the thread engine has wrapper routines for most blocking syscalls and does a best attempt to ensure that the call will only block the thread and not the entire process. This works well for sockets, pipes, ttys etc and fails for files and devices that don't honor non-blocking I/O. CAP