Hi,
I have 2 processes X and Y. Y is exec() from X. In Y i have an exit handler, which is called when i return from main. With in exit handler i delete and object which in turn calls the destructor of the object, which terminates all the threads of Y.
I believe that SIGCHLD is raised by Y as soon as it returns from main().
Or is it done else where.
Sumanth
C programs start with special start-up code that invokes main(). You come back to this stub when you return from main. The stub then invokes exit(). Within exit(), any atexit() routines get invoked. After all of that the system call _exit() is called. The process will never return from this system call...no more user code will run. _exit() will close any open files.
There is a lot of stuff left to be done to shut down the process and different os's do it in different order. One of the things is to send SIGCHLD to the parent. When the parent gets the SIGCHLD signal, the kernel may still be working to finish the _exit() call. If process accounting or C2 security auditing is active this may involve writing records to disk files. But the process is being killed as fast as the kernel can manage it.
One thing though.... System V had a SIGCLD while BSD had a SIGCHLD and they worked differently. Posix boldly decided that the spelling should be SIGCHLD but did not specify which behavior to use. So the parent may be able to set a flag called SA_NOCLDWAIT which will inhibit SIGCHLD from being set at all.
OH!! My state is 
Lot of stuff on SIGCHLD, Thanks for the response.
when _exit system call is triggered none of the atexit used as a exit handler would be invoked and there would not be any flush from std/IO buffer to the kernel buffers as mentioned only file descriptors (if at all open would be closed). It is _exit call which take the status directly to the kernel unlike exit
Writing records to disk files did u mean it from user program's perspective or i misunderstood?
Please explain.
Read again what I posted. I'm not gonna type it again.