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>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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/