On Mon, Jul 23, 2001 at 03:43:27PM -0700, Shawn Wagner wrote:
> On Mon, Jul 23, 2001 at 02:58:09PM -0700, Brent Phillips wrote:
> > I'm glad to hear I'm not insane, or a really bad programmer... :0
> >
> > I've traced my case of this misfortune back to a call to close a socket.
> > When the sockets are left open indefinitely, the app works fine; when
> > closed, it bombs out thinking that there are no threads to schedule. As
> > with Shawn's app, the thread stack sizes are far bigger than they really
> > need to be. Maybe this will trigger some ideas as to what is wrong?
> >
>
> 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.
--
Shawn Wagner
[EMAIL PROTECTED]
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
