MOO-cows Mailing List Archive
Re: ALPHA release of LambdaMOO server 1.7.9
> > 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
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.
Alex Stewart - firstname.lastname@example.org - Richelieu @ Diversity University MOO
"Difficult answers lead to intelligent questions."
Subject Index |