From owner-freebsd-hackers  Mon Mar  6  8:15: 3 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP id 87AE937BDF1
	for <freebsd-hackers@FreeBSD.ORG>; Mon,  6 Mar 2000 08:14:59 -0800 (PST)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id LAA02543;
	Mon, 6 Mar 2000 11:14:48 -0500 (EST)
Date: Mon, 6 Mar 2000 11:14:48 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
Message-Id: <200003061614.LAA02543@pcnet1.pcnet.com>
To: eischen@vigrid.com, tboxberg@schuett-elektronik.de
Subject: Re: Pthread blocking I/O
Cc: freebsd-hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Titus von Boxberg wrote:
> Daniel Eischen wrote:
> > 
> > > Apparently it is not possible to shutdown those
> > > threads from a third thread, neither using close nor shutdown(2) for
> > > the socket I/O if the threads are blocked during read.
> > >
> > > What methods can one use to unblock such a blocked-on-read
> > > thread?
> > 
> > The current implementation of FreeBSD pthreads only grants access
> > to file descriptors to one thread at a time.  I think if one thread
>
> and per direction (?)

Yes, per direction.  I think a close() will try to lock the
file descriptor for both read and write though.

> > tries to close a file descriptor from which another thread is
> > reading, that the thread trying to close will block until the
> > read completes.
> Thanks for your answer!
> 
> What's the reason for locking the file descriptors
> for *all* system calls? especially those I mentioned?

I dunno.  That's the way it was implemented when I started
working on the threads library.  I suppose to protect poorly
written programs from themselves?  I haven't found anything
in the POSIX spec that directly addresses this issue, but I
haven't spent the time to thoroughly read the spec either.
You certainly want to make accesses/modifications to FILE
types atomic/protected, but I think it's the applications
responsibilty to synchronize access to file descriptors for
I/O.  As in your example, I think you should allow one thread
to close a file descriptor while another thread is reading
from it.

Dan Eischen
eischen@vigrid.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message