[MUD-Dev] Re: [CODE] [LANGUAGE/PLATFORM SPECIFIC] My Event Engine

[Todd Lair]

On Sat, 18 Jul 1998 10:55:38 -0600, Chris Gray wrote:

[Chris Gray:]

>As in Oliver's previous reply, there shouldn't be a need to have an
>explictly polled "event" associated with checking the socket for a
>client (or the main connection socket). If, as he mentions, you wish
>to slow the clients down, you can do that by not processing the
>received client input until it is time to do so. If that isn't why
>you are doing an event per socket, then a change could be even
>easier - just get rid of those events. Then, put all sockets on the
>select, and process user input whenever it arrives. The only minor
>flaw with that is that you could start to get behind on processing
>real queued events, if you are continually getting input from users.
>In that case, your server is too busy, and you need to think about
>ways of pacing things.

The motivation for my associating an event with each socket was to
try to eliminate the select call.  Understand, I'm still learning
here, and I may have gone down a path that may prove more costly. 
I'm not trying to slow down clients at all, although I see how I've
done this.  In fact, I had to make my tick time size very minute in
order to have responsive input times.  Much smaller than I would have
prefered.  Although, while the event queues are hardly at full force
yet, the CPU usage of this seems small.

Exactly what I was trying to do was eliminate select call altogether.
 Before reading Oliver's post, I realized that it seemed a waste to
first set the bits in the appropriate fd_sets going through the
entire list of connections, calling select, and then going through
the entire list yet again to determine who has what I/O ready.

I had no previous knowledge of the poll call, and I was pretty elated
to hear that it existed.  I went looking on my Linux 2.0.29
installation for any sign of it.  No man pages and nothing I can find
in the headers.

>The structure I use for this is similar to what you have described,
>but just a bit different in details. I don't partition the events
>into specific "ticks". I just have a queue of events, sorted by their
>ripening times. When the server wishes to go idle, it does a single
>select on all sockets, with a timeout equal to that of the soonest-to-
>ripen event. When it returns, any active FD's are handled (reading of
>user input, sending of data that was blocked, etc.), and if it was
>a timeout, I check the current time, and any events scheduled for
>before or at this time are done. I have a limit in the event loop
>so that it won't do too many before going back to the select - that's
>my small way of keeping user input at higher priority than NPC and
>other time-based events.

I've been thinking about this, and I think I'm warming up to it.  I
don't think there is a practical way to associate individual events
with sockets without the poll call, and I think I can adapt this
method to my tick based event machine fairly easily.  I assume you
only set bits on the output fd_set for things that do indeed have
output?

>Understood. I just mentioned the 'poll' call explicitly to make sure
>no confusion did arise. If its available on your system, you may want
>to look at using it instead of 'select', since it can be more
>efficient in a multi-threaded server than 'select' - see the earlier
>notes in MUD-dev, as Oliver pointed out.

Would you, or anyone else, know if it is indeed available on later
versions of Linux?

Todd