[Prev][Next][Index][Thread]

# Re: ALPHA release of LambdaMOO server 1.7.9

- Date: Tue, 26 Sep 1995 09:47:57 PDT
- From:
- 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

Follow-Ups:

- 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

Home | Subject Index | Thread Index