X-Spam-Check-By:	sourceware.org
Message-ID:	<45C0B10F.3090104@scluk.com>
Date:	Wed, 31 Jan 2007 15:09:03 +0000
From:	"Al Slater" <al DOT slater AT scluk DOT com>
User-Agent:	Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version:	1.0
To:	Cygwin mailing list <cygwin AT cygwin DOT com>
Subject:	Re: hang when using pthread and fork in 1.5.23-1 and snapshot 20070118.
References:	<5C77EDDF-45E1-4165-92EC-C5D364FDB6CC AT rehley DOT net>
In-Reply-To:	<5C77EDDF-45E1-4165-92EC-C5D364FDB6CC@rehley.net>
X-Spam-Processed:	gateway.scluk.com, Wed, 31 Jan 2007 15:09:05 +0000 (not processed: message from valid local sender)
X-Return-Path:	al DOT slater AT scluk DOT com
X-MDaemon-Deliver-To:	cygwin AT cygwin DOT com
X-MDAV-Processed:	gateway.scluk.com, Wed, 31 Jan 2007 15:09:08 +0000
X-IsSubscribed:	yes
Reply-To:	cygwin AT cygwin DOT com
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Rehley wrote:
> Hello,
> 
> One of the applications I've been working with has hanging issues.  It
> will sometimes work properly, and sometimes it will hang and never
> continue through the rest of the program.

I have not done any pthread programming under cygwin, but I have done a
fair bit under Solaris.

In my experience threads and fork are not good bedfellows, you need to
excercise care in order to avoid deadlock.

- From the solaris fork() man page :

  fork() Safety
     If a multithreaded application calls fork() or fork1(),  and
     the  child  does  more  than  simply call one of the exec(2)
     functions, there is a possibility of deadlock  occurring  in
     the  child. The application should use pthread_atfork(3C) to
     ensure safety with respect to this deadlock. Should there be
     any outstanding mutexes throughout the process, the applica-
     tion should call pthread_atfork() to wait  for  and  acquire
     those  mutexes prior to calling fork() or fork1(). See  "MT-
     Level of Libraries" on the attributes(5) manual page.

Using stdio in the child after fork in a multithreaded apps has caused
me pain on many occasions, also std::string in c++.

A recommended way to deal with this that I have seen on the web is to
spawn a process before any threads to handle the forks, and use pipes to
communicate between the threads and the forking process.

- --
Al Slater

Technical Director
Stanton Consultancy Ltd

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFwLEPz4fTOFL/EDYRAmIEAJ43G/LidV+qDdG9Yr2CdxJ2B2L/lwCfTHfI
D1/DfKCQpuda8Kw2OTii51k=
=OaGK
-----END PGP SIGNATURE-----


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -