January 1998
- Mail from mud Zoran's final Imp Stephen Zepp
- Mail from mud Zoran's final Imp coder@ibm.net
- Mail from mud Zoran's final Imp Shawn Halpenny
- Mail from mud Zoran's final Imp JC Lawrence
- Mail from mud Zoran's final Imp Shawn Halpenny
- Happy new year Marian Griffith
- Totally OT... Marian Griffith
- Totally OT... (Or is it?) s001gmu@nova.wright.edu
- Mud-Dev FAQ Ling
- Mud-Dev FAQ Jon A. Lambert
- Mud-Dev FAQ JC Lawrence
- Mud-Dev FAQ Adam Wiggins
- Who's bugging who? : was- Wild West Jon A. Lambert
- my bio (was Mud-Dev FAQ) Mike Sellers
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- request for comments (was: Mud-Dev FAQ) Jon A. Lambert
- request for comments (was: Mud-Dev FAQ) coder@ibm.net
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) s001gmu@nova.wright.edu
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- OT: Suomi Finland Ola Fosheim Grøstad
- OT: Suomi Finland ##Make Nylander
- Totally OT... (Or is it?) (yes it is ;) Marian Griffith
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Adam Wiggins
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Mike Sellers
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Journal of MUD Research, Vol. 3, No. 1 [TEXT] coder@ibm.net
- World Seeding (was Task Parsing) Ling
- World Seeding (was Task Parsing) JC Lawrence
- World Seeding (was Task Parsing) Stephen Zepp
- threaded servers (was request for comments Mike Sellers
- MUD Economy Shawn Halpenny
- MUD Economy Adam Wiggins
- MUD Economy Shawn Halpenny
- MUD Economy Ling
- MUD Economy Brandon J. Rickman
- MUD Economy Marian Griffith
- MUD Economy Shawn Halpenny
- MUD Economy Shawn Halpenny
- MUD Economy JC Lawrence
- MUD Economy Koster, Raph
- MUD Economy Matt Chatterley
- MUD Economy JC Lawrence
- MUD Economy Jon A. Lambert
- OT: Jobs available Koster, Raph
- OT: DCOM and RMI Jon A. Lambert
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Miroslav Silovic
- OT: DCOM and RMI Alex Oren
- OT: DCOM and RMI Chris Gray
- request for comments Miroslav Silovic
- request for comments JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
s001gmu@nova.wright.edu wrote:
>
> On Thu, 8 Jan 1998, Vadim Tkachenko wrote:
>
> > s001gmu@nova.wright.edu wrote:
> > >
> > > On Mon, 5 Jan 1998, Vadim Tkachenko wrote:
> > > >
> > > >Jon A. Lambert wrote:
> > >
> > > ...
> > >
> > > >> Variations on event-driven design
> > > >
> > > >Can you please elaborate on that?
> > >
[skipped]
> > - One thread per connection listener (it's possible to install more than
> > one protocol adaptor, and therefore, connection listener)
> > - One thread per incoming connection
>
> so... at least 2 threads per user?
Of course not - connection listener thread just accept()s the incoming
connections and
spawns the controlling thread
> The decision to go with ticks and a limited number of threads to handle
> the events for a tick stems directly from concerns of system load. I
> don't want to design a game that _requires_ it be the only significant
> process running on a server.
Well, I look at it from slightly different point of view -
- my MUD project is for fun, but this is a guinea pig for every new
idea/concept/technique
- If I would write that seriously, the commercial application is a
target, then why wouldn't I dedicate the computer to run it?
A while ago (in 1992), I heard a joke which bottomline was - "any
mention about the performance UNIX geeks consider obscene". Well, I
laughed, but then, when I came to UNIX, I understood the pun - "if it's
slow, put it in background and forget about it until it's done".
> > Well, a while ago I've been told to implement a Web crawler for a site,
> > and the first thought was - just to go to the root URL, read and parse
> > it and as links appear, spawn other threads using the same algorithm.
> >
> > Obviously, you can parse the HTTP stream much faster than server
> > produces it, and, well, www.best.com (a guinea pig for that task)
> > started to fail when, say, something like 50th request thread was
> > started. Funny, but on my side (Linux, JDK 1.02) nothing bad happened.
>
> As I said, it's very much a result of a lot of factors, including, but not
> limited to cpu speed, threads implementation, compiler, OS, the DB in
> use... etc.
Aha, and I also forgot to think that I was not the only user on the site
at that time, so effectively fail-threshold lies above 50.
> I am unfamiliar with the minSpare/maxSpare management strategy... the
> O'reily PThreads book didn't discuss it, and as that's the only book I
> really have avail... :) Care to give a brief tutorial, or point me to a
> web page? I am a tinkerer at heart, and would prefer an algorithm/design
> strategy to source code, as I prefer to code my own stuff. :)
And I've never heard about PThreads book... See, all my knowledge is 99%
experience-based - you know, when O'Reilly book eats out 50% of your
monthly income (which was true until recently for me), guess what...
OK, so the minSpare/maxSpare strategy is what I saw in Apache HTTPD
(http://www.apache.org).
- You keep at least minSpare spare request handlers, just in case, so
first minSpare incoming
requests arriving simultaneously will be served really fast.
- After some requests are finished, you keep at most maxSpare spare
request handlers, terminating anything extra (variation: after they
expire by themselves).
That's basically it. Also, the implied consideration is you have to have
maxRunning request handlers and never exceed the limit or you're likely
to hit the system limits - just couple of examples:
- Artificial limit on evaluation versions of JDBC implementations
- MAX_THREAD
Also, you may consider dynamically change minSpare, maxSpare and
maxRunning depending on other conditions.
Also, there are two types of requests worth mentioning:
- packet request
- channel request
> mmm.. even in an asynchronous event handler, you can get two events
> targetting the same data executing at 'the same time'. This requires
> either a lockless/rollback method or a data locking method.
Well, there are known methods to resolve this - either mutex semaphores
or synchronized methods in Java (btw, the absense of semaphores in Java
was really annoying, so I recreated them :-)
> Well, when you come down to it, even a so-called asynchronous model is
> still time-slice or tick-based. the system's clock just has a very fine
> grain. I suppose it's a throw-back to paper RPGs. I played a lot of them
> for many years (really haven't played much the past couple... *sigh*), and
> it's hard to break out of the mold they establish.
Yeah, it was different for me - with my computer experience with games
which didn't engage turns (at least, obviously), like Eye of Beholder,
Ultima Underworld, I had no prejudice
> but when I tell my
> character to "cast fireball at bubba", it becomes trivial to implement the
> delay inherent to the action by scheduling the event to go off 3 ticks
> down the road.
By the way, this is exactly the point where extra threads appear in my
model. Every time-based action is asynchronously handled by the separate
thread, which allows to handle effects like spell backfires,
concentration, partial force release, accumulation rules, side effects
with extreme ease.
> yes, you could just as easily let bubba's character wait for however long
> and then generate a 'fireball is cast at bubba from boffo' event, to be
> handled immediately. Either way works. It's just a matter of where you
> choose to do your time and potential interrupt handeling.
See, I do not consider 'cast fireball' as EVENT. I consider it as a
PROCESS.
> > Let me point out one possible common target: if you use the concept of
> > context, or environment, and it's not a fixed value, then ...
> >
> > Like, time, weather in the area, gravity, etc.
>
> mmm.. definately something to consider. Thanks. Anything else I missed,
> anyone? ;)
Just an idea: lycanthrops, whose properties change with a phase of the
moon[s]
> > Two options:
> >
> > - save the event list and process it on the startup
> > - process all the list on shutdown. But, this situation may be more
> > difficult because events being processed may produce some more effects
> > and so on - for example, if you shout (RL) and then try to 'process the
> > event while shutting down', you're likely to:
> >
> > - Hear the echoes,
> > - Which may, in turn, cause the avalanche,
> > - Which may, in turn, kill a lot of people around,
> > - Which, in turn, creates a LOT of other events to process,
> > - and so on.
>
> *nod* good point. I just realized that one of the other things we
> planned to do would work nicely with saving events and processing them at
> re-start... We planned on setting it up so that if you logout outside of
> an inn or other "long-term storage" type safe-room, your character just
> sits there... so, in the event of a... less than expected shutdown, all
> events are saved, all characters out and about are saved as such. reboot,
> all characters are put back, and all events are reloaded. Rather nicely
> takes care of problems like "cast fireball boffo" being reloaded with
> neither the caster or the target being around. I can see players being
> unhappy with the way things would work out, though. It might be better
> to just let the events die.
Bad thing for me, because I'll have a lot of asynchronous events for
each object - for example, I'm going to implement the algorithm of
applying the temporary changes, illustrated by example:
- You get hit by the poisoned sword.
- Consequently, there are two state changes: your limb gets a wound
(let's make it a light one), and you get poisoned.
- Wound is going to heal by itself, slowly (asynchronous process, which,
in according to the abovementioned flexibility, may have variable rate
depending on your state, weather, nutrition etc.)
- Poison is going to continue to affect you (asynchronous process), once
again, with variable rate as above.
In other words, I'm not going to save only the event queue, but also the
[logical] process context, too.
> -Greg
PS: Once again, everything mentioned here is elaborated on
http://vadimt.4cs.com/~vt/gradient, the particular example with a wound
is described under 'Wounds' section, generalized as property modifier.
--
Still alive and smile stays on,
Vadim Tkachenko <VadimT@4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are - Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) Matt Chatterley
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- request for comments JC Lawrence
- Text vs Video; Movies, Books & muds. Nathan Yospe
- Unique items (was: Graphic MUDS/Ultima Online) Vadim Tkachenko
- Unique items (was: Graphic MUDS/Ultima Online) JC Lawrence
- Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Marian Griffith
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Chris Gray
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Unique items Richard Woolcock
- Unique items Jon A. Lambert
- Unique items Vadim Tkachenko
- Unique items Jon A. Lambert
- Unique items JC Lawrence
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Two Tiers Ling
- MUD Development Digest Dr. Cat
- FAQ Ling
- Clients Matt Chatterley
- Clients JC Lawrence
- Clients Shawn Halpenny
- Clients Matt Chatterley
- Event handling - some definitions Jon A. Lambert
- Event Handling Jon A. Lambert
- Simulations - was: 'A flamewar startingpoint.' Jon A. Lambert
- Formatting apology Stephen Zepp
- OT: Insane Wordwrapping Caliban Tiresias Darklock
- OT: Insane Wordwrapping Alex Oren
- Summary Marian Griffith
- Clients Andrew Wilson
- Vast areas in muds Ling
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- Vast areas in muds Mike Sellers
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- META: Web futures for the list JC Lawrence
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Chris Gray
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Caliban Tiresias Darklock
- OT: Socket programming - platform specific Chris Gray
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Nathan Yospe
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Koster, Raph
- Graphical mud perspectives Mike Sellers
- Graphical mud perspectives Koster, Raph
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Nathan Yospe
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads Chris Gray
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads coder@ibm.net
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Vadim Tkachenko
- CORBA, RMI, threads Caliban Tiresias Darklock
- CORBA, RMI, threads coder@ibm.net
- Clients based on Netscape 5? Greg Munt
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Marian Griffith
- Clients based on Netscape 5? coder@ibm.net
- OT? The impact of the web on muds Mike Sellers
- The Anti-Mac Interface JC Lawrence
- 3D graphics (Was: The impact of the web on muds) Jon Leonard
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) Mike Sellers
- 3D graphics (Was: The impact of the web on muds) Chris Gray
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- VRML Becomes ISO/IEC International Standard (fwd) Nathan Yospe
- Arctic's Project? Brandon Cline
- Arctic's Project? Adam Wiggins
- Arctic's Project? Brandon Cline
- Arctic's Project? Chris Gray
- FAQ Marc Eyrignoux
- Java and Javascript Greg Munt
- Java and Javascript Chris Gray
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Chris Gray
- Java and Javascript Jon Leonard
- Java and Javascript Matt Chatterley
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Mike Sellers
- Java and Javascript J C Lawrence
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Travis Casey
- Java and Javascript Jon A. Lambert
- Java and Javascript Sauron
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Alex Oren
- Java and Javascript Chris Gray
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- MetaVoice, MetaFont Ling
- MetaVoice, MetaFont Richard Woolcock
- MetaVoice, MetaFont Vadim Tkachenko
- MetaVoice, MetaFont JC Lawrence
- MetaVoice, MetaFont Chris Gray
- The MLI Project Vadim Tkachenko
- The MLI Project Marc Eyrignoux
- The MLI Project Vadim Tkachenko
- The MLI Project coder@ibm.net
- The MLI Project Ling
- The MLI Project coder@ibm.net
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Travis Casey
- The MLI Project Travis Casey
- The MLI Project coder@ibm.net
- The MLI Project s001gmu@nova.wright.edu
- The MLI Project Vadim Tkachenko
- The MLI Project Travis Casey
- The MLI Project Stephen Zepp
- The MLI Project coder@ibm.net
- The MLI Project Travis Casey
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Andrew C.M. McClintock
- The MLI Project Ling
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Niklas Elmqvist
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Caliban Tiresias Darklock
- The MLI Project J C Lawrence
- The MLI Project Chris Gray
- The MLI Project Koster, Raph
- The MLI Project J C Lawrence
- The MLI Project Vadim Tkachenko
- Races and stuff (was: FAQ) Vadim Tkachenko
- Races and stuff (was: FAQ) Marc Eyrignoux
- Races and stuff (was: FAQ) Vadim Tkachenko
- OT: I'm moving again! JC Lawrence
- MUD Development Digest Dr. Cat
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Adam Wiggins
- Administrative Responsibilities Greg Munt