Re: ALPHA release of LambdaMOO server 1.7.9

• Date: Tue, 26 Sep 1995 19:16:35 PDT
• From:
  Alex Stewart <riche@crl.com>
• Cc: MOO-Cows@parc.xerox.com
• In-Reply-To: <95Sep26.094758pdt.6404@silk.parc.xerox.com> from "Pavel Curtis" at Sep 26 95 9:47 am

> > 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."

• Re: ALPHA release of LambdaMOO server 1.7.9
• From: Pavel Curtis <pavel@parc.xerox.com>

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