Re: [Qemu-devel] [PATCH] opengl rendering in the sdl window

[Anthony Liguori]

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
>