Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2004:
[Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dial
Home

[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]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#8491) Re: Freeciv commit: kauf: A new connect dialog for the client. This allo...
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Mon, 12 Apr 2004 09:29:28 -0700
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8491 >

On Mon, Apr 12, 2004 at 08:58:16AM -0700, Jason Short wrote:
> 
> <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.

I disagree. Freeing memory which is assumed to be valid
everytime/everywhere in the client is a problem. You also have to
problem that the atexit handlers are called twice (newborn child and
normal client). So can you guarantee that nothing bad happend if
rl_callback_handler_remove, TTF_Quit or SDL_Quit is called twice?

> 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.

Ack.

> > 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).

So someone (me?) has to write a test for _Exit and use _exit if this
fails?!

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Understanding is a three-edged sword; 
  your side, their side, and the truth."
    -- a well-known Vorlon




[Prev in Thread] Current Thread [Next in Thread]