[MUD-Dev] Re: [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine
Todd Lair
tlair at mailzone.com
Sat Jul 18 01:19:36 CEST 1998
On Fri, 17 Jul 1998 19:51:11 -0600, Chris Gray wrote:
>[Todd Lair:]
>
> >Now, as far as the polling for both types of sockets, I'm wondering if there isn't a more
> >efficient way than what I'm doing. What I'm doing is using select, however, I'm only
> >setting the single bit for the the descriptor in question for all three fd_sets. This seems
> >like a big mistake to me, since I imagine, as the descriptors get larger in number, that the
> >select call has to see if each bit is set for the lower descriptor numbers till it gets to the
> >single set one.
>
>[Chris Gray:]
>
>I didn't quite follow all of that, but I'll ask this question: where
>does your server spend its time waiting if it has nothing to do? Mine
>spends its time in a single 'select' call, which contains the fd-bits
>for the main connection socket, and all client sockets. I'm not
>multi-threaded, so that is easy for me to do.
Ok, maybe I should start from the beginning. I have my
"event engine" set up as an array of link lists. The
engine also maintains a variable called current which is
the current index into that array representing the current
tick. The size of the array represents the largest number
of ticks in the future an event can be scheduled. When a
client requests an event to be added to the engine, the
client passes the number of ticks (which has to be less
than the size of the engine's array) that need to transpire
before the event is ripened. The engine uses this number +
current to figure out its place in the array (wrapping when
going past the physical length of the array). Each tick,
current is incremented (again wrapping to index 0 when
current is equal to size of array). After current is
incremented, all events in that link list are removed and
executed. Between ticks, the engine uses select to "sleep"
for the time remaining for this tick. If there were no
events executed, the sleep lasts the full tick time. I
wake up every tick, increment current, and see if there are
any events in current's link list.
Each player and the master socket, gets its own individual
event associated with it. When this type of event ripens,
it means that this single socket needs polling to see if it
has input, output, or an exception. read: not all the
sockets, but the one. My question again, is how should I
go about determining the read, write, exception status.
Currently, I'm using select, setting a single bit in each
of the fd_sets for the descriptor. This doesn't seem ideal
to me, since over time, the descriptors get higher in
number value, and the select call has to scan the fd_sets
to see where the single bit is set in each of the sets.
I was wondering if I should just use recv (possibly passing
the the peek parameter) to determine the status of the
descriptor that needs to polled. I was wondering what
returns I need to worry about, and if this would be a much
more efficient method opposed to the select call on the
single descriptor.
>What is it that "ripens" your events to trigger the polling? In general
>polling (as opposed to calling the 'poll' SysV socket call), is a bad
>idea, since your CPU is busy doing things without accomplishing much.
>Polling is used in some circumstances in order to get the absolute
>minimum latency, but that is usually in situations where the CPU is
>dedicated, or when what it is waiting for is guaranteed to be ready in
>a very short period of time.
I've been using polling as a term to describe the process
of determining whether or not the descriptor has read,
write, or exception status. Sorry for the confusion.
>My goal is that when there is nothing for my server to do, it will use
>no CPU time at all. Now, the NPC's will be doing things, but in the
>intervals when none of them is active, the server should be idle.
I hope mine will do the same. Minus the CPU time needed to
check whether there is anything in the current's link list,
processing events, my server will sleep.
Todd
More information about the mud-dev-archive
mailing list