[Home] [Groups] - Message: [Prev in Group] [Next in Group]
5291: Re: [MUD-Dev] Event handling (was: request for comments)
[Full Header] [Plain Text]
From: JC Lawrence <claw@under.Eng.Sun.COM>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 15 Jan 1998 20:31:41 -0800
References: [1]
Organization: Kanga.Nu
On Mon, 12 Jan 1998 07:43:01 PST8PDT
s001gmu <s001gmu@nova.wright.edu> wrote:
> On Sun, 11 Jan 1998, JC Lawrence wrote:
>> Note: "event" is actually a very poor term for what we are
>> describing here. They really aren't events, but I'm unsure of a
>> better name for them.
> Actions?
Hurm. Not bad.
>> Certainly. You create an event chain (as above) which iteratively
>> saps the character's strength and vitality. Should that process
>> happen to kill the character (strength == 0?) then this will be
>> noticed by the normal methods of the character object (probably in
>> the accessor for the strength attribute) and processed from there.
> As I understand it, the only difference is that he shortcuts the
> event chain by having the running thread (process in his terms)
> handle all of the delays by going to sleep, rather than scheduling a
> new event to go off X ticks down the road.
> There are some advantages to doing it that way... You can have the
> thread sleep by using pthread_cond_timedwait (assuming you are using
> posix threads) , and use the condition var as an interrupt signal,
> allowing for very gracefull interruption and interrupt handling. If
> you want to interrupt a pending event in an event queue, you have to
> search the queue, or have some kludgy structure imposed above the
> queue to allow for easier access, etc.
There is a significant implication in this system however. It
effectively requires that you use a locking model, as to not use a
locking model would have most sleeping threads fail due to other more
rapidly commiting threads interfering with their data references.
Conversely, if you do go for a locking system the problem is then
preventing the system from bogging down to a worse-than serial
execution case as the events all contend and lock-wait for shared
data.
--
J C Lawrence Internet: claw@null.net
Internet: coder@ibm.net
----------(*) Internet: jc.lawrence@sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...