[274] in Pthreads mailing list archive
Re: pthreads, read() and linux
daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Thu Feb 22 14:55:10 1996
To: Todd Enersen <tee@dgsystems.com>
Cc: pthreads@MIT.EDU
In-Reply-To: Your message of "Wed, 21 Feb 1996 17:38:47 PST."
<Pine.SOL.3.91.960221173441.29692A-100000@eggo.dgsystems.com>
Date: Thu, 22 Feb 1996 14:01:17 EST
From: Christopher Provenzano <proven@MIT.EDU>
>
> 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
