[6] in Pthreads mailing list archive
Re: timed reads
daemon@ATHENA.MIT.EDU (Christopher Provenzano)
Fri Jun 9 16:51:13 1995
To: Greg Hudson <ghudson@MIT.EDU>
Cc: pthreads@MIT.EDU, rsalz@osf.org
In-Reply-To: Your message of "Fri, 09 Jun 1995 11:52:24 EDT."
<199506091552.LAA23516@glacier.MIT.EDU>
Date: Fri, 09 Jun 1995 16:31:54 EDT
From: Christopher Provenzano <proven@MIT.EDU>
> > Short of using select() or the non-standard timedread(), the
> > cleanest way to code something like this may well be to have the
> > timer thread simply close() the descriptors in question [...]
>
> > I have no idea what would happen in Chris Provenzano's
> > implementation..
>
> I believe the close() will block on the read(). You can call
> shutdown(sock, 1) to shut down further sends, which will send a TCP
> close packet and cause the other side to close the connection and
> terminate the read()... but not if the other side has disappeared off
> the net.
>
The internals of pthreads serializes accesses to an individual descriptor
to prevent all the ugly race conditions that can occure. (like closing
a connection while someone is reading from it.) Because sockets are full
duplex I have serialized the read side and the write side. The routine
close() needs to aquire the lock for both before issuing the kernel close
because it affects both, but shutdown(sock, 1) only affects the write side
and therefor only nees to aquire the write side lock.
The timedread routine is called read_timedwait(), and there is a timed
variant for write(), send(), recv(), sendto(), recvfrom(), sendmsg(), and
recvmsg() also. These could be implemented with select() or poll() but
lose the atomiticity, which pthreads gaurentees within the process.
CAP
