From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=58754 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PkEwZ-0006mD-HP
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 07:02:48 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1PkEwY-0004AT-Ph
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 07:02:47 -0500
Received: from mail-yw0-f45.google.com ([209.85.213.45]:65155)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1PkEwY-0004A3-Kl
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 07:02:46 -0500
Received: by ywa8 with SMTP id 8so2716047ywa.4
	for <qemu-devel@nongnu.org>; Tue, 01 Feb 2011 04:02:46 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <20110201103222.GC1725@redhat.com>
References: <1296537693-16406-1-git-send-email-mohan@in.ibm.com>
	<1296537939-16649-1-git-send-email-mohan@in.ibm.com>
	<20110201103222.GC1725@redhat.com>
Date: Tue, 1 Feb 2011 12:02:45 +0000
Message-ID: <AANLkTi=YruNp-MBbFwZSNJ2SzJd7ScnwYrJgsQBjLs4t@mail.gmail.com>
Subject: Re: [Qemu-devel] [V4 PATCH 2/8] Provide chroot environment server
	side interfaces
From: Stefan Hajnoczi <stefanha@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: blauwirbel@gmail.com, "M. Mohan Kumar" <mohan@in.ibm.com>, qemu-devel@nongnu.org

On Tue, Feb 1, 2011 at 10:32 AM, Daniel P. Berrange <berrange@redhat.com> w=
rote:
> There is a subtle problem with using fork() in a multi-threaded
> program that I was recently made aware of in libvirt. In short
> if you have a multi-threaded program that calls fork(), then
> the child process must only use POSIX functions that are
> declared 'async signal safe', until the child calls exec() or
> exit(). =A0In particular any malloc()/free() related functions
> are *not* async signal safe.

In this particular patch the fork() call happens quite early so the
risk should be low but it would be nice to investigate this issue
fully.

Stefan