Re: [LONG]Strange Loop

From: Benjamin Draper (
Date: 05/20/00

*realises his over enthusiasm at a quick fix

Chris Gilbert wrote:
> Nope you've got a bug.  It's set to zero at the top of the function

 Yup, I see that, but where would the bug be? I've eliminated it being a
problem with anything I've added by using bpl11, bpl12, bpl16 and bpl17
*stock* code. This just suddenly 'happened' on Wednesday, and only
occured once before and the solution was to reboot the machine.

 Select appears to be the problem, as null_time is trashed after the
select() here, in comm.c:

     /* Poll (without blocking) for new input, output, and exceptions */
    if (select(maxdesc + 1, &input_set, &output_set, &exc_set,
&null_time) < 0) { <-----
      perror("SYSERR: Select poll");

 from the man page for 'select':
> int  select(int  n,  fd_set  *readfds,  fd_set  *writefds, fd_set
> *exceptfds, struct timeval *timeout);
> ...
> This causes problems ... when code is ported to Linux that reuses
> a struct timeval for multiple selects in a loop without
> reinitializing it.  Consider timeout to be undefined after select
> returns.

 As you said in your first reply, if select returns an error, null_time
could become undefined, so is using null_time in this way a bad thing?
Or is my MUD host the problem? I can put in a throwaway timeval struct,
setup like null_time, so null_time isn't trashed, but is this the right
way to go about it?

Argh. Thanks for humouring me =)

-> Ben

     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     |  |

This archive was generated by hypermail 2b30 : 04/10/01 PDT