On Mon, Jul 23, 2001, Shawn Wagner wrote:
> [...]
> > After looking at pth_sched.c, here's what I think is happening:
> >
> > All threads are sitting in the wait queue waiting for various events to
> > happen, and the ready queue is empty. When pth_scheduler() tries to get the
> > next ready thread to run, there aren't any, and instead of checking the wait
> > queue for events that have occurred again (By calling
> > pth_sched_eventmanager()), it aborts. I'm going to try changing that bit of
> > the scheduler and see if it helps.
>
> With some more debugging, it looks like using hard syscall wrappers is the
> problem. Turning that off makes everything work for me, at least (Linux
> 2.2). With them, pth_sched_eventmanager() isn't always detecting fd i/o with
> a timeout correctly and was exiting early instead of waiting for an event to
> happen. This is annoying, since one of the threads does gethostbyaddr()'s,
> which I didn't want possibly blocking the whole server. But at least it's
> not aborting now.
Hhmm... so you think it is not a semantical bug in the scheduler, but
instead a side-effect of some syscalls. What happens if you use the soft
syscall wrappers? Do you have a _SMALL_ test application at hand which I
can use to deterministically reproduce the problem?
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
