Re: -persist and the wxWidgets terminal, continued

[<tim...@en...>]

Dave Denholm wrote:
> Timoth=E9e Lecomte <tim...@en...> writes:
>
>  =20
>>>>> gnuplot can fork(), then allow the parent to exit, leaving the chil=
d
>>>>> continuing to run the same code in exactly the same state, but
>>>>> detached.
>>>>>          =20
>
>
>  =20
>>>> and because exiting
>>>> the parent would close file and socket descriptors, thus closing the
>>>> connection to the X server.
>>>>
>>>>        =20
>>> No, the child inherits the open files.
>>>
>>>      =20
>> It does, but when the parent calls exit(), the corresponding files are
>> closed. There is a workaround : _exit(), but again, I think it becomes
>> too complicated and less portable.
>>    =20
>
> exit() can cause problems, but it doesn't close the files and
> sockets. Or at least, it closes the parent's handles, but the child's
> handles mean the underlying instance remains open.
>
> Parent exit() does cause stdio to get cleaned up, which can confuse
> things.
>
> I rather assumed that as soon as we started discussing fork() we were
> in a unix-only scenario.
>  =20
The unix-only was my assumption too. As far as the exit()/_exit() stuff=20
is concerned, here is a quote from the gtk+ FAQ :

"5.5. Why does this strange 'x io error' occur when I fork() in my GTK+=20
app? [GTK 2.x]

This is not really a GTK+ problem, and the problem is not related to=20
fork() either. If the 'x io error' occurs then you probably use the=20
exit() function in order to exit from the child process.

When GDK opens an X display, it creates a socket file descriptor. When=20
you use the exit() function, you implicitly close all the open file=20
descriptors, and the underlying X library really doesn't like this.

The right function to use here is _exit()."

According to 'man 2 exit', the only difference between exit() and=20
_exit() is that the former executes all the functions registered in=20
atexit(), whereas the former doesn't. I guess the Xlib automatically=20
registers one of those, and get confused when exit() is used.

Then, my conclusion is that fork() could indeed be used, but I still=20
wonder if it's worth coding it.


>>> One other option would always be to immediately fork, but keep the
>>> parent around as a dummy process (just so that the original process
>>> knows it's still active). So all the work would happen in the child.
>>> In effect, code it as if you always detach, and then keep the parent
>>> alive as a workaround to stop the original process thinking the child
>>> has exited until the child chooses to detach.
>>>
>>>      =20
>> I wonder what happens regarding the command line then.
>>
>>    =20
>
> Shouldn't really notice anything happening. Both parent and child have
> stdin open, (or maybe parent closes it), but only child is actually
> reading from it, and so it doesn't matter.
>
> (After all, if you launch gnuplot interactively from a shell, the
> shell still has the stdin stream open. But it just isn't reading from
> it.)
>  =20
Thank you very much for your explanations ! It's nice to understand=20
fork() a little bit more.

Best regards,

Timoth=E9e