On Thu, 22 Oct 2009 15:55:33 -0700, Daniel Yek <dyek@xxxxxxxx> wrote: > That is, the multi-threaded app. creates a dummy child process during > its initialization process and use the child solely as a surrogate > parent to fork on behalf of the app. That way, the multi-threaded app. > doesn't have to fork and possibly leaking "states" in the child > (especially, if it is not followed by an exec(), I think.) > > I'm interested in hearing from the more experienced devs. regarding this > technique too. That works if you have a stand-alone program that forks "early", though this really is not too nice. You need to transmit the executable program parameters over some IPC mechanism. Also, this incurs some obvious memory and CPU overhead. However, most multimedia frameworks are layered into libraries and plugins, so they don't have their own process to fork early enough, so they cannot do that. In my particular bug, we have the ALSA plugin leaking the descriptor, and the XDG screensaver plugin doing fork-and-exec. Synchronizing those two is not really an option. -- Rémi Denis-Courmont _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
