MOO-cows Mailing List Archive


Re: ALPHA release of LambdaMOO server 1.7.9

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?



Home | Subject Index | Thread Index