Date: Thu, 18 Sep 2008 19:27:47 +0200 From: David Naylor <naylor.b.david@gmail.com> To: Daniel Eischen <deischen@freebsd.org> Cc: Tom Evans <tevans.uk@googlemail.com>, freebsd-current@freebsd.org Subject: Re: FreeBSD deadlock (with fork?) Message-ID: <200809181927.52384.naylor.b.david@gmail.com> In-Reply-To: <Pine.GSO.4.64.0809181308140.19815@sea.ntplx.net> References: <200809180631.47071.naylor.b.david@gmail.com> <200809181857.25872.naylor.b.david@gmail.com> <Pine.GSO.4.64.0809181308140.19815@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart12811148.oDATbWqooN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 18 September 2008 19:13:19 Daniel Eischen wrote: > On Thu, 18 Sep 2008, David Naylor wrote: > > On Thursday 18 September 2008 15:33:52 Tom Evans wrote: > >> On Thu, 2008-09-18 at 06:31 +0200, David Naylor wrote: > >>> Hi, > >>> > >>> I have a program that spawns a lot of subprocesses (with pipes open) > >>> from multiple threads. The problem is the program often deadlocks, b= ut > >>> not consistently. Sometimes the program can run over 5 times to > >>> competition without incidence and yet othertimes it locks within a few > >>> seconds. > >> > >> Do you create threads, which then fork(), or do you fork() and then > >> create threads? > > > > I have many threads that then fork. (aka forking threads). > > > >> I think the former will not work.. > > > > Is there any reason for this and is this a FreeBSD limitation or a > > general problem? > > No, the former will work. You can fork() from threads, only as long > as your forked processes only call async-signal-safe functions or > some form of exec(). For instance, you can't fork and then create > new threads from that child process. If you are not immediately > exec()'ing from the child process, then you have to be careful > and only use async-signal-safe functions. > > Remember that you have multiple threads in the parent, so the > state of libthr, libc, etc may be inconsistent in a child > process. If you have a look at the backtrace from my original post you will see that= =20 all my threads are getting locked. The program I am using is python and th= e=20 call that is forking is Popen(['some', 'program'], stdout=3DPIPE,=20 stderr=3DSTDOUT). As far as I know it just sets up the pipes and does an=20 execvp. (See=20 http://svn.python.org/view/*checkout*/python/tags/r252/Lib/subprocess.py?co= ntent-type=3Dtext%2Fplain&rev=3D60915=20 from line 981 to 1091). [[I tried appending close_fds=3DTrue to the argume= nt,=20 it appeared to make the program deadlock less often...]] Any ideas as to what might be causing this dead lock (and why all the threa= ds=20 are stopping in amd64 specific assembler)? --nextPart12811148.oDATbWqooN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBI0o+YUaaFgP9pFrIRArHCAJ4unxSPffSggossGz7l1Gz0LF8xugCfci3D c8wugKdG9K5F8CapMNITo7Y= =nEFp -----END PGP SIGNATURE----- --nextPart12811148.oDATbWqooN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809181927.52384.naylor.b.david>