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

[s001gmu at nova.wright.edu]

On Mon, 20 Jul 1998, Todd Lair wrote:

> 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.

If each socket has an explicitly associated event, (IE: when the event
goes off, it knows what socket to look at, and it passes that info on to
the next generated event), why not just use a non-blocking read/write
call?  If I understand the way select() works, it essentially does that
for all the FD's in the FD_SETs.  

something like:

handle_socket_check_event (int fd)
{
  if (read(fd,...) != 0)
    handle_input(...);

  if (pending_output(fd))
    if ( (c = write(fd, ...)) != 0)  // I believe write returns the number
                                     // of bytes written.
      update_pending_output_buffer(fd, c);

  if (check for exceptions here)
    // do socket exception code here

  schedule_event('handle_socket_check_event', fd, time);
}

This, of course, assumes you have set the I/O up as non-blocking ahead of
time.  If you are unsure how to do that in *nix, I can send a block of
sample code.

> 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.

Yeah... it seems awfully ugly.  I've spent many an hour pondering a
gracefull way around that.

[poll() vs select()] 

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

I have no idea.  My first guess is that it would be part of the libc, and
not part of the kernel, but my knowledge of where the line lies betwixt
libc and the kernel is admitedly lacking.  I haven't looked for it on my
2.0.30, but I don't recall seeing it mentioned in any of the patch
notices.

Have you tried to just compile a program with a call to poll() in it?  :)
Also, you may try grepping the source and lib paths for it.  It may be
sans man page, but actually exist.  *shrug*

-Greg