Re: ALPHA release of LambdaMOO server 1.7.9

• Date: Tue, 26 Sep 1995 09:47:57 PDT
• From:
  Pavel Curtis <pavel@parc.xerox.com>
• CC: MOO-Cows@parc.xerox.com
• In-reply-to: Alex Stewart's message of "Mon, 25 Sep 1995 18:49:24 PDT" <9509260049.AA0059@localhost>

Alex Stewart writes (in unintentionally private mail):
> > -- Added the built-in function `set_connection_option(CONN, OPTION,
> >    VALUE)', for controlling various optional behaviors on the connection
> >    CONN.  The only allowed values for OPTION in this release are as
> >    follows:
> > 	"hold-input" -- if VALUE is true, then input received on CONN will
> > 	    never be treated as a command; instead, it will remain in the queue
> > 	    until retrieved by a call to read().
> 
> One question here.. does this affect suspend-detection on read() calls if a 
> task associated with a "hold-input"ed queue suspends?  I.e. can I:
>     set_connection_option(player, "hold-input", 1);
>     suspend(0);
>     set_connection_option(player, "hold-input", 0);
>     ...
>     x = read();
> 
> ..and have it not E_PERM?  If not, could this be arranged?  It would be 
> _extremely_ useful under some circumstances (in particular, in conjunction 
> with the notify() changes in 1.7.9), and now that "hold-input" exists the 
> primary reason for E_PERMing after suspend() (namely that input would be 
> processed during the suspend, screwing up all predictability of input 
> destinations) can be avoided.

I'm not averse to such a change, but the detailed specification is unclear to
me.  Can you make a detailed suggestion as to what the rule should become for
E_PERMing on a read() call?

	Pavel

• Re: ALPHA release of LambdaMOO server 1.7.9
• From: Alex Stewart <riche@crl.com>

• Prev: ALPHA release of LambdaMOO server 1.7.9
• Next: Re: ALPHA release of LambdaMOO server 1.7.9
• Index: MOO-cows
• Thread: MOO-cows