Re: fork, exec, _exit

[Owen Taylor <otaylor redhat com>]

"Sergey V. Udaltsov" <sergey oudaltsov clients ie> writes:

> A couple of days ago I noticed one problem with forked processes. In my
> code, the child process is doing nothing but exec(). And in case of
> problems - exit(). After some investigations (great thanks to Ivan
> Pascal) it was found that GNOME/GTK is doing a lot of stuff using
> atexit.

GTK+-2.x no longer makes any use of atexit(). [Well, the -fb backend
does, but that's not really mainstream. ]

 So the only correct way to close the child is to call _exit()
> (but not exit()!). Which is not too good - the program itself may want
> to add some atexit hooks. So my question is - why does it all work this
> strange way? Why GNOME/GTK could not have GtkTerm/GnomeTerm functions to
> close/stop/term/finalize everything - and only main process would have
> to call them. AFAIK, the current usage of atexit in GNOME conflicts with
> the multi-process programming and X Window architecture (the connection
> to X server should be used and closed in the same one process).

Note that forking in an X process is always a risky thing; I haven't
fully investigated, but it is quite possible to get X confused
if you have multiple processes open on the same connection.

GTK+-2.2 supports multihead programming - you can open and close
multiple displays using gdk_display_open() / gdk_display_close()
 
> BTW, even current situation is not properly documented AFAIK. I found
> the confirmation for this image in some mailing lists' archives. It
> would be great to document the problem at least (in Gtk FAQ there are
> special lines about threads, but nothing about processes).

 http://www.gtk.org/faq/#AEN472

Regards,
                                        Owen