|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window |
Date: | Mon, 08 Sep 2008 14:57:29 -0500 |
User-agent: | Thunderbird 2.0.0.16 (X11/20080723) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |