Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA24841; Thu, 22 Feb 96 23:49:22 EST Received: by MIT.EDU id AB27728; Thu, 22 Feb 96 20:34:17 EST Date: Thu, 22 Feb 96 20:34:17 EST From: MAILER-DAEMON@MIT.EDU (Mail Delivery Subsystem) Subject: Returned mail: Deferred: Bad file number Message-Id: <9602230134.AB27728@MIT.EDU> To: ----- Transcript of session follows ----- 550 erk@pearl.att.com... Host unknown 451 jhahn@candy.snu.ac.kr... reply: read error jhahn@candy.snu.ac.kr... reply: read error 451 tanteikg@iscs.nus.sg... reply: read error tanteikg@iscs.nus.sg... reply: read error 421 clem.systemsix.com.tcp... Deferred: Connection timed out during user open with clem.systemsix.com 451 ryan@stcs.com.sg... reply: read error ryan@stcs.com.sg... reply: read error 421 cip.informatik.uni-erlangen.de.tcp... Deferred: Connection timed out during user open with faui45.informatik.uni-erlangen.de 554 jf@ap.co.umist.ac.uk... timeout waiting for input 451 jf@ap.co.umist.ac.uk... reply: read error jf@ap.co.umist.ac.uk... reply: read error 421 immd3.informatik.uni-erlangen.de.tcp... Deferred: Connection timed out during user open with faui45.informatik.uni-erlangen.de 451 durian@boogie.com... reply: read error durian@boogie.com... reply: read error ----- Unsent message follows ----- 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