# ALPHA release of LambdaMOO server 1.7.9

Alex Stewart (riche@crl.com)
Tue, 26 Sep 1995 19:16:35 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    > > 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?

    Well, I haven't really dug through this area of code to find out what's
    feasable and what isn't, but my feeling would be that it should E_PERM if the
    task has ever suspended while the input queue associated with the task (i.e.
    the one it would be read()ing from) wasn't "held", but if all suspend()s up to
    this point have been while the queue was held, then it should be able to
    read() ok.

    One way to accomplish this might be to have the input queues keep a "current
    task" value, which gets changed every time the command-parser-input-scanner
    looks at them and they're not "held" (whether there's input which it passes to
    the command parser or not), and then have read() make sure that the input
    queue is still set to the current task (i.e. there hasn't been a chance for
    input to slip through to the command parser since the current task started)

    Alternately, I suppose a suspend()ed task which is resuming which the MOO sees
    has a held input queue could get the same task_kind as it had before it
    suspended.. not sure if this would screw other things up, though.

    The more I think about it I'm not sure how easy this'll be to implement
    cleanly, but you know the code a lot better than I do, so..  It would be
    really useful, though.

    -R
    -------------------------------------------------------------------------------
         Alex Stewart - riche@crl.com - Richelieu @ Diversity University MOO
                             http://www.crl.com/~riche/
                "Difficult answers lead to intelligent questions."