Re: cvs commit: src/lib/libthread_xu Makefile pthread.map src/li
: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>
討論串 (同標題文章)
完整討論串 (本文為第 14 之 24 篇)：