[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

19019: Re: [MUD-Dev] Re: TECH: Distributed Muds

[Full Header] [Plain Text]
From: J C Lawrence <claw@2wire.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 26 Apr 2001 20:31:37 -0700
References: [1] [2] <-newest
Organization: Kanga.Nu
On Thu, 26 Apr 2001 13:53:24 -0600 
Christopher Kohnert <cjkohner@brain.uccs.edu> wrote:

> You know, I've been curious. I've tried to get that sort of idle
> time in some prototype servers I've implemented. Granted, I have a
> sort of nasty requirement in that my 'tick' needs to be in 1/100th
> of a second. I've done a blocking select on the sockets but found
> the latency for commands entered on any of the sockets to be too
> unbearable. My question is how you achieve a 90% idle rate with
> any sort of responsive sockets. Perhaps a simple usleep() with no
> actual blocking select? I'm just curious because I've found that
> anything other than a tight non-blocking polling loop is just
> 'laggy'.

I've never liked the base concept of a select() looping process that
tried to do real work between select() calls.  It can work to be
sure, but it has always smelled of playing with fire.

I prefer having a thread dedicated to socket IO, pulling in and
buffering the IO as received, and then handling compleated blocks
off to one or more queues (depends on whether you do pre-sorts) for
the other game systems to pick up and process appropriately.  There
are several advantages, not the least of which is that you decouple
your command/entry model from your processing model.  

--
J C Lawrence                                       claw@kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev