看板 DFBSD_commit 關於我們 聯絡資訊
:The management thread should be avoided, that introduces complex into :userland, I don't want to go old evil linuxthread way. :I only need one flag to indicate that the thread now executes in :kernel(pthread_exit() calls _exit()), so its userland resource is no :longer needed, e.g. its userland stack and user thread control block, so :other threads can reuse them when creating new thread or recycle it at :sometime later, but without this flag, there is always a race condition, :it is not safe to reuse it because that thread may be still using the :stack, although it called _exit(), but that does not say it is not using :the stack! calling _exit() pushes return address on stack, and it :destroys another thread's memory if the stack was reused by other :threads very quickly. :In detail, I want following feature: :a syscall allows userland to set an userland address, for example: :__sys_set_thread_exit_addr(int *addr), it remembers the addr :in kernel thread structure, if the thread calls _exit(), :in kernel, kernel code writes a value to addr, that's the only :thing I need to do userland garbage collection. :In this way I can avoid complex of management thread. : :Cheers, :David Xu Hmm. Well, I really dislike adding single-purpose system calls. If I do this we need to try to make the system call a bit more general-purpose. For example, we could use it to detect abnormal thread termination as well as deal with the stack resource race in the normal thread-exit case. So something like this: __sys_set_exit_data(int *addr, int data); Defined to be: "When a process exits the system will store the specified data into the specified address. Only one address may be registered per process. The feature can be disabled by passing addr = NULL. In an rfork/thread baesd system this may be used to detect abnormal process exits and to synchronize stack resource reuse with normal thread termination." How's that? -Matt Matthew Dillon <dillon@backplane.com>