[Home] [Groups] - Message: [Prev in Group] [Next in Group]
7836: [MUD-Dev] Re: [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine
[Full Header] [Plain Text]
From: oliver@jowett.manawatu.planet.co.nz
Newsgroups: nu.kanga.list.mud-dev
Date: Sat, 18 Jul 1998 18:24:00 +1200 (NZST)
References: [1]
Organization: Kanga.Nu
On Sat, 18 Jul 1998, Todd Lair wrote:
> 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.
I assume that the reason you're checking individual sockets via events is
due to some command-parsing requirement, eg. commands won't be processed
until N seconds in the future after some action by a player.
Why not move this to a separate layer? At the lowest level, select() on
ALL sockets with a timeout equal to the time to next pending event. When
input arrives, read and buffer; when output is possible, write from a
buffer; when exceptions occur, set an appropriate flag. Loop back and
repeat the select. Then when the event actually goes off, you check and
modify the buffers.
Think of it as a wrapper around recv() et al. to avoid making many "real"
syscalls. The implementation of the wrapper could be different - the same
high-level model could apply to, say, using a pool of threads to handle
I/O, I suspect.
-O