[Xfce4-commits] r19323 - libxfcegui4/trunk/libxfcegui4

Brian J. Tarricone bjt23 at cornell.edu
Sat Jan 7 10:21:28 CET 2006

Hash: SHA1

On 1/7/2006 1:09 AM, Jasper Huijsmans wrote:
> Brian J. Tarricone schreef:
>>On 1/6/2006 2:52 PM, Danny Milosavljevic wrote:
>>>Author: dannym
>>>Date: 2006-01-06 22:52:03 +0000 (Fri, 06 Jan 2006)
>>>New Revision: 19323
>>>   libxfcegui4/trunk/libxfcegui4/xfce-exec.c
>>>live dangerously by doing the child_watch / do not reap child
>>>thing that surely will kill us with SIGCHLD one day
>>Danny, are you sure this is really a good idea?  Personally I'd rather
>>we do something like calling setsid() so the new process gets its own
>>session.  That way, if, say, I start an app from the panel, and then
>>later kill the panel, the app doesn't die too.  (Actually I think the
>>panel doesn't use xfce_exec() anymore, but you get my point.)
>>So what we should do here is provide a GSpawnChildSetupFunc to
>>gdk_spawn_on_screen() that does nothing but call setsid().  I'm pretty
>>sure that doing this makes it unnecessary to add the child_watch_cb.
> SIGCHLD is ignored by default, isn't it?


> Also, the panel does use xfce_exec for launchers.


> I'm also not sure g_spawn_async doesn't already
> detach child processes if you don't pass a location to store the pid.

I don't know either.  It definitely doesn't call setsid(), but it
appears that it sometimes does some funky thing with fork()ing an
intermediate child, and then fork()ing another child from there that
actually does the exec().  It's all rather confusing.  All I know is
that sometimes (the "sometimes" bothers me) when I've launched
applications from the panel, xfdesktop, or xfwm4 (via keybindings before
the new shortcut editor), and then killed that respective parent app,
the children have, on occasion, died.

Personally I'd feel better with a child setup function that just
explicitly calls setsid() on platforms that have it.

Version: GnuPG v1.4.1 (MingW32)


More information about the Xfce4-dev mailing list