Subject: Re: suspend() thougths (sic) [really, REALLY sick!]

From: Andrew Wilson <[email-masked]>
Date: Sat, 18 Sep 1993 09:30:09 -0700

Explicitly atomic (uninterruptable) verbs?  I like it, go for it, but don't
expect LambdaCore to be up to using it for decades.  Mebbie someone could come
up with $semaphore or something?!

Mmm, if a +a verb is called, when if ever will it time out.  Should it be given
15k ticks and then die if it hasn't returned already or should it go on forever,
(at least until it runs out of things to do).  If the latter is the case then
maybe +a verbs should only be able to run with .wizard perms, just so that
noone can write:

	@program $nasty:spam +a
	while (1);
	endwhile;
	.

Now if +a verbs do arrive then presumably everyone will want to be able to use
them (to protect critical regions of their code, property assignments etc.).
But since, for security reasons, +a verbs are wizdusted ONLY, then it's gonna
make things pretty frantic while wizards chase round the core rewriting
everyone's critical regions for them.  Messy.  So mebbies [I am 30 and I speak
like a child!] $semaphore could be used to supply critical region functionality
in a secure way:

	@program $coolthing:gaga
	while (!$semaphore:lock(this, verb))
		suspend(1);
	endwhile;
	"Do something critical";
	this.foo = 1;
	$semaphore:unlock(this, verb);
	.

Where we have:

	@program $semaphore:lock +a [#somewiz]
	object_to_lock = args[1];
	verb_to_lock = args[2];
	if ( { object_to_lock, verb_to_lock } in this.locks )
		return 0;
	else
		this.locks = { @this.locks , { object_to_lock, verb_to_lock } };
		return 1;	
	endif;
	.

	@program $semaphore:unlock +a [#somewiz]
	object_to_lock = args[1];
	verb_to_lock = args[2];
	this.locks = setremove(this.locks, { object_to_lock, verb_to_lock });
	.

Ok, the logic may be wrong, and it's simplified anyway to avoid complicating
the issue [specifically ANYONE can :unlock an ob:verb regardless of who
originally locked it], but the details are better left to people who know what
they're talking about (ie. not me).

But, etc.

Comments,

	Andy (Net).

ps.  Just because the new task model, implicit in joe's proposal, will perform
'automatic' suspends as an when a task requires them doesn't mean that explicit
suspends should be done away with.

+a, scary stuff indeed.

er, what does ass-backwards mean?

---

From: [email-masked]
Date: Sun, 19 Sep 1993 18:48:41 -0700

> Mmm, if a +a verb is called, when if ever will it time out?  
> Should it be given 15k ticks and then die if it hasn't returned already or
> should it go on forever, (at least until it runs out of things to do).

Tasks which have part of their execution occur with an 'a' verb on their call
stack would be subject to all of the limitations any other task would have, in
the way I'm imagining things.

This does raise an interesting dillema, however.  Theoretically, 'a' verbs (or
now, verbs which purposefully do not call suspend()) need to perform some
operations on several properties on an object in an uninterrupted way, or get
output to the user NOW before any other task can.  This is really impossible
to be sure of in the current system, since a high load on the MOO-running
machine can make just about anything run out of seconds.  I'm not going to
lose sleep over this -- the time limit on verbs is sufficiently high right now
so that this problem won't occur very often.  But it does make one think ...

> But since, for security reasons, +a verbs are wizdusted ONLY,

Not at all.  'a' verbs have the same general semantics as verbs which
purposefully do not call suspend().  They run out of seconds and ticks just
like they do now.  One of the benefits of having an 'a' bit will be being able
to detect when some wise ass stuck a suspend() call in a utility verb you're
using, for example.

The main goal is that '!a' verbs don't have to stick :suspend_if_needed()s
in all of the loops -- this can be done for them automatically.  I'd say make
all verbs '!a' if it weren't for the fact that some need to do atomic property
updates or atomic output.

> ps.  Just because the new task model, implicit in joe's proposal, will
> perform 'automatic' suspends as an when a task requires them doesn't mean
> that explicit suspends should be done away with.

Agreed.  Backward compatability, etc.

> +a, scary stuff indeed.

Not nearly as frightening as clear properties (ha ha).