From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcmsQ-0006wg-JH for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:58:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcmsO-0006ub-Ag for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:58:21 -0400 Received: from [199.232.76.173] (port=50674 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcmsO-0006uW-7i for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:58:20 -0400 Received: from hs-out-0708.google.com ([64.233.178.242]:14053) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KcmsN-0007lE-Rg for qemu-devel@nongnu.org; Mon, 08 Sep 2008 15:58:20 -0400 Received: by hs-out-0708.google.com with SMTP id k27so299428hsc.2 for ; Mon, 08 Sep 2008 12:58:19 -0700 (PDT) Message-ID: <48C583A9.8090006@codemonkey.ws> Date: Mon, 08 Sep 2008 14:57:29 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window 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> <20080908194834.GC13612@shareable.org> In-Reply-To: <20080908194834.GC13612@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: qemu-devel@nongnu.org Jamie Lokier wrote: > 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. > But you still leak if both processes are killed at once (think killall qemu-system-x86_64). An exec would be a little safer but it's pretty hideous. > What do Gtk and/or Qt and/or Gecko do? They're likely to have thought > about it. > It's not a problem for Gtk because the window of possibly leaking is so short. It creates the shmid, send it to the x server, shmat, then shmctl. The key point is that it interacts with the X server synchronously so not much bad can happen while it's talking to the X server. It's probably not a huge problem in practice, but I've never liked this. Sys V shared memory is really just crappy. Regards, Anthony Liguori > -- Jamie >