On Tue, 2010-04-20 at 20:02 -0400, Ari Pollak wrote: > severity 578476 important > thanks > > I don't consider using the public API of gstreamer in a non-broken way > to mean that pidgin is doing anything wrong here. Comment from the > source explaining why they were originally catching/disabling forking: > > /* By default, gstreamer forks when you initialize it, and waitpids for the > * child. But if libpurple reaps the child rather than leaving it to > * gstreamer, gstreamer's initialization fails. So, we wait a second before > * reaping child processes, to give gst a chance to reap it if it wants to. > * > * This is not needed in later gstreamers, which let us disable the forking. > * And, it breaks the world on some Real Unices. > */
Not sure what exactly the problem here is, maybe you can explain in what way libpurple could reap the child process? Because multiple threads are running while fork() is called and the libpurple threads continue in the new process? Anyway, I don't think this is still a problem since 0.10.28. Nowadays it's not a simple fork() and doing things in a copy of the original process but a fork() and exec() of a different executable, which then talks via pipes to the original process. Or am I missing something here? Oh and if you do the registry updating in the main process the pidgin process will always use a lot more memory... not a good thing either ;)
signature.asc
Description: This is a digitally signed message part
