Benjamin Draper wrote:
>
> *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");
> return;
> }
>
> 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.
If you read closely it also says that if it's zero select returns
immediatly so it shouldn't be updated. I'd suggest sticking in some
code to check the value after the select. IE is it updated (I don't
think it should be)
> 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?
maybe your select needs this but it sound's like a bug with select, as
patrick suggested try updating the kernel.
Cheers,
Chris
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT