OSDev.org

Hi!
What is the best method to implement the atexit system call?
Do I have to use callbacks from the kernel and if whats the best method to return to the kernel after the execution of the callback functions?

best regards

I implement it entirely in userspace; when exit() is called from the C code, it runs the list of things given to atexit(), then does the kernel exit syscall. I don't think that the atexit() handlers have to be called if the process is killed by the kernel directly, only if the process calls exit() or abort(). If this were not true, then atexit() would have to be a system call, but Linux does not have a matching one, so by contradiction I'm pretty sure I'm right about that.

I haven't implemented atexit, I used the one in newlib but I think the callbacks should be in userspace. Generally the exit() function handles calling the atexit() functions and closing stdio streams and then calls the OS with _exit(). This of course means that atexit() needn't be a system call and can do all its work in userspace too.

[Edit: Ooops, took too long. I agree with NickJohnson]

Thank you for your quick answers. I dont know what to make of callbacks to userspace. they sound rather evil.

But I have another question. I am a little stuck with multithreading. The problem is where does the function called in the new thread return to?
I thought about implementing a routine in a library where the thread returns to, which then calls exit_thread.

best wishes

megatron23 wrote:I dont know what to make of callbacks to userspace. they sound rather evil.

I don't know why they would be evil. What we are saying is that the entire atexit mechanism is in userspace. The atexit() function creates a list of functions to call when the process exits. When the process calls exit() all the atexit handlers are called and once everything is cleaned up the 'real' _exit() system call is made. I believe this is the implementation in every UNIX.

megatron23 wrote:The problem is where does the function called in the new thread return to?
I thought about implementing a routine in a library where the thread returns to, which then calls exit_thread.

Common practice is to put the address of an exit routine (usually written in assembler) on the stack of each new thread at creation so that when the thread returns from its main function the exit routine will be called. That assembler stub can manipulate the stack so that the return value is passed to your exit_thread() function which may eventually make a system call.

gerryg400 wrote:I don't know why they would be evil. What we are saying is that the entire atexit mechanism is in userspace. The atexit() function creates a list of functions to call when the process exits. When the process calls exit() all the atexit handlers are called and once everything is cleaned up the 'real' _exit() system call is made. I believe this is the implementation in every UNIX.

Yes, I like that approach implementing the call in userspace only. I meant if I had to do it from kernel space that this would be evil.

gerryg400 wrote:Common practice is to put the address of an exit routine (usually written in assembler) on the stack of each new thread at creation so that when the thread returns from its main function the exit routine will be called. That assembler stub can manipulate the stack so that the return value is passed to your exit_thread() function which may eventually make a system call.

I don't quite get it. How would the kernel know the address of the exit routine. Is it passed with the create_thread syscall?

megatron23 wrote:I don't quite get it. How would the kernel know the address of the exit routine. Is it passed with the create_thread syscall?

Yes, I added an extra field to the pthread_attr_t structure. This puts the onus on userspace to get it right. I try to make my kernel agnostic to this type of stuff and put everything into libc.