[DGD] Another mudlib requirement

[Felix A. Croes]

Steve Wooster <swooster at xprt.net> wrote:

> At 12:33 AM 2/14/2004 +0100, you wrote:
> >The latter will probably modify the object, and if it commits before
> >any of the callout-adding threads, they will be cancelled because
> >they accessed a version of the object's state which is now out of
> >date.
>
>      This caused me to wonder something... if I wrote a thread that took an 
> insane amount of CPU, and therefore a really long amount of time to 
> complete, would it be possible that it might end up getting postponed 
> indefinitely? For example: (assume this object has infinite rlimits)

Note that such a thread always accesses the object that it starts in,
since starting effectively involves the deletion of a callout from the
object's callout table.

This is a good question.  I haven't made my decision yet, but I think
that I will not let parallel threads start in the same object.  So for
this object, the thread that starts first would finish first, and the
next one might be delayed.

Note that threads won't be cancelled indefinitely.  Eventually, DGD/MP
will run them in such a way that they cannot be cancelled by any other
thread.

Regards,
Dworkin
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd