patacongo commented on issue #1263: URL: https://github.com/apache/incubator-nuttx/issues/1263#issuecomment-650806116
Related: pthread-specific data destructors are not currently implemented. They need to be and when they are, these destructors must also run in user-mode, in the context of the pthread. This solution proposed here is to move part of pthread_exit() into user-space at libs/libc/pthread. That differes from the solution in the TODO proposed list. The TODO list solution is overly complex and not on the roadmap for a good Unix solution: One longer term objective is to move all of the pthread logic out of the kernel and into libs/libs/pthread. The pthreads interfaces are not part of the kernel in other Unix-like implementations. The kernel does provide certain necessary hooks, but the majority of the implementation of the pthread logic is implemented in libpthread, in user-space and not within the kernel. This is a model that I think that NuttX should follow as well, but things are not well structured to do that now. Rather, I am rather here to divide pthread_exit() into two pieces: A user space function called pthread_exit() the resides in libs/lib/pthread/lib_pthread_exit.c and a kernel space functions, say nxthread_exit() that resides in sched/pthread/pthread_exit.c: 1. pthread_exit() in libs/lib/pthread/lib_pthread_exit.c would execute when the thread exits. It would only do the things that need to be done in the same context as the pthread execution environment. This would including executing all of the pthread_cleanup functions. That would would have to be migrated from sched/pthread/pthread_exit.c. It would also include the new logic to execute the the new pthread-specific data destructors. And, finally, is would all the nxthread_exit() system function. 2. nxthread_exit() would become a system call (replacing the existing system pthread_exit() system call in syscall/ and in include/sys/syscall*.h. 3. nxthread_exit() would essentially be the existing pthread exit logic sans pthread_cleanup function calls. This sounds straight forward, but there is a complication: We also have to catch the case were the pthread main function does not call pthread_exit() but instead just returns. Currently that is handled in the function pthread_start() in sched/pthread/pthread_create.c. In FLAT mode, it just calls the pthread main function; in other modes it calls up_pthread_start() which will switch to user mode. I have not thought through all of the details, but this would require changes like: 1. Instead of calling the pthread main function, pthread_start() would call a trampoline function in user-space. This already happens in the PROTECTED mode via the pthread_startup() function in the userspace_s structure. But not in KERNEL mode. In KERNEL mode, it uses the SYS_pthread_start system call to start the pthread main function directly. 2. pthread_start would not call pthread_exit(). 3. The trampoline function in user space would simply call the pthread main function and call pthread_exit() is the pthread main function returns. Hmm.. The kernel gets the address of the pthread trampoline from the userspace_s structure. How would the kernel know the address of a process specific pthread thread trampoline function in the KERNEL mode? I am not sure right now. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
