From owner-freebsd-threads@FreeBSD.ORG Fri Jul 15 20:16:32 2005 Return-Path: X-Original-To: freebsd-threads@freebsd.org Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D000A16A41C for ; Fri, 15 Jul 2005 20:16:32 +0000 (GMT) (envelope-from julian@elischer.org) Received: from postoffice.vicor-nb.com (postoffice.vicor.com [69.26.56.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id F148A43D4C for ; Fri, 15 Jul 2005 20:16:31 +0000 (GMT) (envelope-from julian@elischer.org) Received: from localhost (localhost [127.0.0.1]) by postoffice.vicor-nb.com (Postfix) with ESMTP id BE4C64CE7BF; Fri, 15 Jul 2005 13:16:31 -0700 (PDT) Received: from postoffice.vicor-nb.com ([127.0.0.1]) by localhost (postoffice.vicor-nb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43427-02; Fri, 15 Jul 2005 13:16:31 -0700 (PDT) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by postoffice.vicor-nb.com (Postfix) with ESMTP id 1474E4CE7BC; Fri, 15 Jul 2005 13:16:31 -0700 (PDT) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 080FA7A424; Fri, 15 Jul 2005 13:16:31 -0700 (PDT) Message-ID: <42D8199E.1060702@elischer.org> Date: Fri, 15 Jul 2005 13:16:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050629 X-Accept-Language: en, hu MIME-Version: 1.0 To: Guy Helmer References: <42D691F2.3030201@palisadesys.com> <42D6BA3E.1000306@elischer.org> <42D7BBB8.9050207@palisadesys.com> In-Reply-To: <42D7BBB8.9050207@palisadesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postoffice.vicor.com Cc: freebsd-threads@freebsd.org Subject: Re: system scope threads entering STOP state X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2005 20:16:33 -0000 Guy Helmer wrote: > Julian Elischer wrote: > >> >> >> 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 for the explanation. I was that the other threads would be > stopped during a fork(2) but it looked to me like the STOP would be > brief. You were *what*? "aware"?, "suspicious"? :-) > > Would an "uninterruptible wait" include system calls like a write(2) > of a large buffer? That would explain it... it's hard to say.. Possibly yes, if it had to allocate buffer space. However this is a question for others.. Is it possible to duplicate this on request? > > Thanks, > Guy >