Subject: Re: Bug in read()

From: Andrew Wilson <[email-masked]>
Date: Mon, 24 Aug 1992 15:55:18 -0700

Hi,

	low, middling, (alcohol, in case you're interested),

H. Peter Anvin ([email-masked]) says:

>There seems to be a bug in read() with the following sympthom: [sic]

>If the player connection subjected to read() disconnects while read() is
>active, the reading task locks up instead of returning an error message.  I
>got my SMTP client working, except that it never returns, and cannot
>process status output for the reason.

I assume you mean 'player' in terms of a player who's actually logged in.

Alternatively, if a verb of yours does:

	connection = open_network_connection(<whatever>);
	fork (0)
		while (1)
			line = read(connection);
		endwhile;
	endfork;

and if, at some later time, you type:

	;boot_player(x);

the error IS caught.  If your verb is in debug mode then you get a trace-back
indicating the line with the read(connection) statement on it.  The same error
is caught if the site you're connecting to does a ;boot_player().

This information is offered, not as a solution to Peter's problem but as
an indication of read()'s behaviour under other 'extreme' conditions.
I think it would be helpful to the MOO community if there was an official
statement about the semantics of open_network_connection(), read() and
other 'low-level' functions in the event of a break in the connection involved.
I realise that o_n_c() is undergoing some degree of review at the the moment,
however, would anyone in the know care to comment further, the manuals are
not as helpful as they could be.

Thanks,
	Andy.  (Net<whatever> @ <Forget it.  It's been a long night and if I
		start worrying about trivial matters now I'm NEVER gonna
		make it!>)

ps.	I'm running server version 1.6.1, LambdaCore-6Aug92.db with only my
	MOO-net code in addition.

pps.	The way Ripley died.  That was SOOO moving.  I think I'm going to
	cry all night.

---

From: [email-masked] (H. Peter Anvin N9ITP)
Date: Mon, 24 Aug 1992 16:24:05 -0700

> is caught if the site you're connecting to does a ;boot_player().

In one of my verbs I had this loop

this.io = {};
this.active = 1;

conn = open_network_connection(<stuff>);

fork(0)
   <Stuff that among other things reads from this.io>
   boot_player(conn);
endfork

while ( typeof(rl = read(conn)) == STR )
   this.io = { @this.io, rl };
endwhile

this.io = { @this.io, "999 Connection closed" };
this.active = 0;

... well, the connection opened and closed, but the while() loop never fell
thought, which it ought to have done since read() should have returned an
error.  My experiments *seem* to indicate that the problems occur when the
other side closes the connection before the boot_player() is reached, but
I am not 100% certain.

	/hpa

-- 
INTERNET:  [email-masked]   TALK:      [email-masked]
BITNET:    HPA@NUACC     IBMNET:    16334@IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  [email-masked]
"Kissing a smoker is like licking an ashtray."  -- R. Heinlein

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 2 Sep 1992 15:50:09 -0700

There was, indeed, a bug in read() such that, if there was no pending input on
the connection (i.e., the read()ing task had already gobbled it up) and the
connection was then closed (from either side), then the read()ing task would
never resume.  This has now been fixed; the fix will appear as part of release
1.7.0, hopefully coming later this week.

Brief status report on 1.7.0:

Ref-counting is done and appears to be working wonderfully.  We've also
dramatically improved the performance of property-value lookup, which was the
next speed bottleneck in line.  Also, the notion of `clear' property values,
through which you can see the value of that property in the parent, is now
implemented and working.  This latter feature should allow for a major space
savings, since child objects whose properties haven't been changed since
creation have all their properties clear, so that they don't duplicate the
values in the parent.  We're going to apply this notion to LambdaMOO's DB
retroactively today or tomorrow and we're expecting a major drop in space.

The new multi-networking stuff, also scheduled for 1.7.0, is not yet ready, but
what I've done so far makes me hopeful that it shouldn't be much longer.

	Pavel