On Tue, 2006-06-20 at 16:03 -0400, Mystilleef wrote:
> My application is a GUI designed especially for GNOME. Thus, when my
> application is launched, I register it with the GNOME libraries and then
> instruct the kernel to create a separate process for the application.
> The procedure is called forking. The effect of this is that when my
> application is launched from a shell terminal, the kernel detaches it
> from the shell terminal's process, therefore making the application run
> in its own process.
There are plenty of situations where this behaviour is exactly not what
I want, and not forking doesn't hurt anyone. The panel, run dialog and
so on spawn processes so they are not bound to anything (you can
demonstrate this by running a program from the panel and then killing
the panel).
Primary use case for not forking is that it makes it trivial to write a
script that launches a program, user does something in it, and then the
script can continue when the program has exited. If Gedit forked when
it started I wouldn't be able to use it as $EDITOR in cvs commit for
example.
Why break this use case because you think that forking is useful, when
to the average user there is no difference and to the terminal-using
folks not forking is very useful at times. Yes, if you start a number
of not-forking processes from a terminal and then close the terminal
without disowning them they will also die. Luckily the users who will
start a program from a terminal are advanced enough to know that
happens[1].
Ross
[1] In other news this week was the first time I got a bug report from a
Sound Juicer user who when I asked "run SJ in a terminal and paste the
output" asked "what's a terminal?". Yay non-geek users!
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Attachment:
signature.asc
Description: This is a digitally signed message part