[8] in Pthreads mailing list archive
Re: timed reads
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Jun 9 17:04:30 1995
From: Ken Raeburn <raeburn@cygnus.com>
Date: Fri, 9 Jun 1995 16:47:00 -0400
To: Christopher Provenzano <proven@MIT.EDU>
Cc: pthreads@MIT.EDU
In-Reply-To: Christopher Provenzano's message of Fri, 09 Jun 1995 16:31:54 EDT <9506092031.AA05888@jimi.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.
Bill's scenario sounds the most reasonable. Especially if the read is
going to wait forever because the remote host really did vanish.
Can't close() grab some lock to prevent editing of the file table, set
a "closing" flag, and wake up any threads blocked on the file
descriptor?
