[Qt-interest] return to command line but the GUI is still alive

[Colin S. Miller]

Srdjan Todorovic wrote:
> Hi,
> 
> On 26/01/2010, Thiago Macieira <thiago at kde.org> wrote:
>> Remember these rules about fork():
>>
>> 1) one side must either execve() or _exit(). That's a strict rule and
>> independent of Qt.
> 
> Did you really mean ::_exit(...) instead ::exit(...) ?
> I thought it was acceptable to use ::exit(...).
> 
> Thanks,
> Srdjan

_exit() stops the process immediately.
exit() and falling off main()
returns code-flow back to the C Runtime Library (CRT).

The CRT will call any functions registered with atexit(),
any functions registered for running during exit
in other libraries, and possibly release any
resources allocated by the CRT itself.


I can't remember the details, but it is something like this.
The CRT defines
void *__atExitRegister=0;
in the section .data$exit_A
and
void *__atExitRegisterEnd=0;
in the section .data$exit_Z

Each library that want to be called during exit
defines a symbol in the section
.data$exit_*
where '*' is any letter.
This symbol is a
void(*fnPtr)(void)

This section (or symbol) is marked to be always be linked when
any other section from the object is referenced. (This is a special
flag in the section).
The linker will merge all .data$* sections in strict alphabetical
order of section name into the end of the .data section.

The CRT can then call all the functions listed between
__atExitRegister and __atExitRegisterEnd.
There is a similar process used at start up;
This means that the CRT can be configured to only initialise,
say stdio or the heap if the program actually uses these.
This means that unused libraries don't need to linked in.



Here endth today's lesson in the internals of the CRT and linker.



Anyway,
the clean up in the parent branch of fork() can confuse the kernel
about the state of resources shared between the parent and child.


HTH,
Colin S. Miller (who's had to study this in too much detail)