*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.
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: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT