RĂ©mi Denis-Courmont wrote:
On Thu, 22 Oct 2009 15:55:33 -0700, Daniel Yek dyek@real.com wrote:
Could it be that the answer is to use the surrogate parent model? Book: Pthreads Programming: 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.
Hi,
[Not trying to say that it is a solution or I know a lot about the model, but just to comment on the possibility more...]
I suppose in the crude way, the program can call the multimedia framework's init function early to fork the surrogate parent and provide forking services. Plugins, etc., should use the framework's service, instead of simply fork.
I further suppose that the a fork-exec DSO can be created and the LD_PRELOAD mechanism used to "redirect" all fork() and exec() (and what-else) to the DSO implementation, which utilizes the DBus 1-to-1 IPC (for convenience, or any custom wire protocol) to the surrogate parent, which then implements fork(), exec(), waitpid(), etc.
I'm not sure yet if DBus provides file-descriptor-passing services, if not, fds can be passed (explicitly -- not great, cumbersome, but it might be necessary) the way it is -- using another Unix domain socket connection, if necessary.
XDG screensaver can be called in a child process too -- the surrogate parent is adequate for this too.
There is a possibility that this model can work, but I have never actually trying it out, just thinking about it often. If this works, it would be a great addition to Glib.
I hope there are other more experienced people chime in to offer (appreciated) comments.
Regards,