delorie.com/archives/browse.cgi | search |
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/
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |