Re: Questions about ListenThread loop Eric Messick (eric@syzygy.com)
Thu, 14 Jan 1999 00:30:09 -0800

In message <4.1.19990113225717.00a26990@ricochet.net>, "Mark S. Miller" <markm@caplet.com> wrote:
>Here's the main loop inside the ListenThread:
>
> while (!myTerminateFlag) {
> Socket clientSocket;
> try {
> clientSocket = myListenServerSocket.accept();
> } catch (IOException e) {
> Trace.comm.errorm("exception in ListenThread accept()", e);
> continue;
> }
> if (myTerminateFlag) {
> clientSocket.close();
> break;
> }
> if (mySuspended) {
> clientSocket.close();
> } else {
> setupNewConnection(clientSocket);
> }
> }
>
>1) Do we really want to "continue" on an IOException? When I sleep and
>wake my laptop, it seems to break the socket, and the loop just repeats the
>error report at high speed. What else can break a ServerSocket? Should we
>try to detect if the socket's been broken? Can we? (Within the Java API,
>it's not obvious to me how to do so.) If we do determine it's broken,
>should we try to construct a new one? Should we try to construct it on the
>same port, or should we expect a timeout to prevent that?

I recall a temporary failure as a result of a botched tcp negotiation or something like that. There wasn't any obvious way to tell the difference between a one time failure, and a permanent one. You can't re-listen() on the same port without a rather lengthy timeout (1-5 minutes as I recall). For an os-allocated port, there's no gurantee you'll be able to get the same one back at all. You effectively have to go offTheAir() and back onTheAir() after getting a permanent failure. Not a happy thing to have to do. Probably correct behavior for sleeping a laptop, though. Be nice to have the offTheAir() happen before you sleep, but it probably doesn't matter.

>2) What's mySuspended supposed to be about? Currently it's a private
>instance variable initialized to false, never set, and tested only in the
>above code.

Looks like the old "can't interrupt an accept()" thing. You remember your friend the UserThread, right? My guess is that while suspending the process, we wanted not to accept connections in order to insure that the run queue drained. It probably goes offTheAir instead, which would set myTerminateFlag.

-eric