[Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dial
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
<URL: http://rt.freeciv.org/Ticket/Display.html?id=8491 >
Raimar Falke wrote:
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8491 >
>
> On Mon, Apr 12, 2004 at 02:40:25AM -0700, Raimar Falke wrote:
>
>>>+ /* these won't return on success */
>>>+ execvp("./ser", argv);
>>>+ execvp("./server/civserver", argv);
>>>+ execvp("civserver", argv);
>>
>>>+ /* This line is only reached if civserver cannot be started,
>>>+ * so we kill the forked process.
>>
>>>+ * Calling exit here is dangerous due to X11 problems (async replies) */
>>>+ _exit(1);
>>
>>We use exit in a lot of other places. Can someone provide further
>>informations?
>
>
> Ok the explanation goes like this: the client has registered atexit
> handlers (freeciv and maybe also X11). These get overwritten if we
> successful replace the process image with exec*. In the error case
> however a call to exit() would still call the atexit handlers and this
> isn't a good idea.
>
> So the mentioning of the X11 problems is misleading. It is a general
> problem.
I think there's no problem with internal atexit() handlers. These
generally just free memory or something. However the library atexit
handlers may do more complicated things; in the case of the X library
they probably send a message like "delete the window" to the X server.
But since there's just one window this isn't good.
A related problem arises if the exit() call is left off entirely. Now
we have one X window being used by two processees. I've written this
bug before and it took me a while to figure out what was going on.
The moral of the story is that if the exec fails we want the child
process to just go away.
> So _exit is used. But _exit isn't the best choice since C99 contains
> _Exit with the same semantics (don't call atexit handlers).
From "man _exit":
CONFORMING TO
SVr4, SVID, POSIX, X/OPEN, BSD 4.3. The function _Exit() was
intro-
duced by C99.
so _exit() should be safe enough. If any systems have problems we can
switch to _Exit or add configure checks.
Note that we don't blindly use C99 features anywhere. We always have
configure checks for them (some of these configure checks fail outright
if the feature isn't present, however).
jason
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Mike Kaufman, 2004/04/12
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Raimar Falke, 2004/04/12
- [Freeciv-Dev] (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Vasco Alexandre da Silva Costa, 2004/04/12
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Raimar Falke, 2004/04/12
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Raimar Falke, 2004/04/12
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo...,
Jason Short <=
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Jason Short, 2004/04/12
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Raimar Falke, 2004/04/12
- [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo..., Jason Short, 2004/04/12
- [Freeciv-Dev] (PR#8491) problems with new connectdlg code, Jason Short, 2004/04/16
|
|