On Thu, Jan 03, 2002 at 06:03:00AM -0800, Aaron Bannert wrote: > Good theory, but in my trace we were only looking at the PID of the parent > process, where there aren't any threads (* technically there is only > 1 thread). It is almost certainly a bug somewhere, since consuming CPU > without bounds while performing a non-CPU-intensive task is unexpected > behavior. In our case we run waitpid() followed by select() with a > timeout of 1 second (to emulate a sleep()).
If I do a debug of libc_r, I see a lot of calls to select() that are initiated by the userland scheduler. So, we can not trust any select() calls in the ktrace output as they will be part of the libc_r internals. This happens regardless if you have threads or not for all processes that link against libc_r. > My guess is we're using a blocking call somewhere in worker that is > not posting an event that the select()-based scheduler can use to do a > context switch on. > > apr_thread_yield() anyone? That doesn't seem to be the case here. The kernel scheduler isn't detecting the event and it definitely has code in their to *try* to detect it. My vote is to try and fix the scheduler. -- justin
