From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kcmj1-0003BA-UH
	for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:48:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kcmj0-0003AL-8h
	for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:48:39 -0400
Received: from [199.232.76.173] (port=51669 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kcmiz-0003A8-Uz
	for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:48:38 -0400
Received: from mail2.shareable.org ([80.68.89.115]:47262)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1Kcmiz-0006Bh-II
	for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:48:37 -0400
Date: Mon, 8 Sep 2008 20:48:34 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window
Message-ID: <20080908194834.GC13612@shareable.org>
References: <48C16207.5090808@eu.citrix.com>
	<20080905165536.GA12606@redhat.com>
	<48C168CE.5040700@eu.citrix.com> <48C348D3.6070702@codemonkey.ws>
	<20080908134140.GF4947@shareable.org>
	<20080908134833.GQ2315@redhat.com> <48C53D24.8030803@redhat.com>
	<20080908150759.GB8465@shareable.org>
	<20080908154700.GT2315@redhat.com> <48C54D62.5060509@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <48C54D62.5060509@codemonkey.ws>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

Anthony Liguori wrote:
> shmget()
> shmat()
> 
> ...
> 
> notify server of key
> wait for server to confirm shmat()
> 
> ...
> 
> shmctl(IPC_RMID)
> 
> ..
> 
> shmdt()
> 
> Which leaves a huge window open where bad things can happen.  The client 
> can exit, the client can crash.  This is particularly troublesome in a 
> library because it's really not nice to try and register an atexit() 
> handler or something like that from a library.

Another way to do it, which ought to be quite reliable, is to fork()
(and maybe exec) a child helper process which calls shmget() then
prints out the ID, for the parent to read, then waits on its input.
There is also a pipe from parent to child.  If the parent closes the
pipe to child or dies, the child kills the shm ID immediately.  This
catches all kinds of parent crashing and deliberate kills, and you can
still close the pipe as soon as the parent confirms everyone is
attached to the segment.

What do Gtk and/or Qt and/or Gecko do?  They're likely to have thought
about it.

-- Jamie