Date: Thu, 14 Jul 2005 12:17:18 -0700 From: Julian Elischer <julian@elischer.org> To: Guy Helmer <ghelmer@palisadesys.com> Cc: freebsd-threads@freebsd.org Subject: Re: system scope threads entering STOP state Message-ID: <42D6BA3E.1000306@elischer.org> In-Reply-To: <42D691F2.3030201@palisadesys.com> References: <42D691F2.3030201@palisadesys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Guy Helmer wrote: > I have a long-running multithreaded process on FreeBSD 5.4 (SMP, > PREEMTPION, SCHED_4BSD) linked with libpthread and I'm creating the > threads with attribute PTHREAD_SCOPE_SYSTEM. The threads need to be > processing input in near-real-time or its input buffers overflow. > > I've modified the program so that a thread can fork/execl/waitpid > (without WNOHANG) to use an external program for further processing on > a batch of input (sometimes via a pipe, other times via writing to a > file). However, even under a light input load, the program is now > dropping input. While running top(1) in thread mode, I occasionally > find all the program's threads are in the STOP state for several > consecutive seconds. Is there anything related to the frequent use of > fork, execve, or wait4 that would be likely to cause such a > situation? I'm not seeing anything obvious in my reading of the > kernel sources. duirng a fork the parent process is in a variant of the "STOPPED" state, or, rather, if you look at top -H you should see that all teh threads except for that doing the fork, are in the STOPPED state. This is because while a thread is forking the process needs to be single threaded so that there is a consistent image to be copied to teh child. the single threaded state is also enterred for exit() and execve(), though that should not affect your program. I can't imagine why the state would persist for any length of time, unless there is another thread that is in an uninterruptible wait. In that case the other threads have to wait for it to complete what it is doing and come back. I have considerred whether such a thread should not be considerred "already suspended" and in fact some earlier versions of the code did that, however it leads to some inconsistancies and the danger that such a thread will be suspended holding some resource that it should not hold for any length of time. > > Thanks in advance for any help, > Guy >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42D6BA3E.1000306>