Re: cvs commit: src/lib/libthread_xu Makefile pthread.map src/li
:...
:>>1. Each thread has its pid, and getpid returns different value
:>> for every thread.
:>
:>
:> I'm not sure how to best handle this. I'll have to check how
:> much work is involved in aggregating the various statistics
:> for one process or alternatively teach top / ps / ... to deal
:> with multiple struct proc instances sharing a pid.
:>
:>
:>>2. Signal is broken. there is no feature to send signal to a process
:>> as a whole, it does not conform with POSIX. SIGSTOP and SIGCONT
:>> does not work correctly.
:>
:>
:> Should be relative easy to add by keeping track of rfork groups.
:>
:>
:Not that easy, giving a pid, you have to find a right thread not
:masked the signal, and delivered it to that thread, if no thread
:unmasked it, it should be put in shared process pending set, it
:is relied on how do you implement a threaded process, how to map
:a pid to such thread group.
This is an area that probably needs a good going over and a rewrite.
If we want to support 'native' threads then we want an RF_CLONE for
rfork that allows us to create multiple 'threads' with the same PID.
This means that we have to remove all uses of p_pid in the kernel to
reference a process structure and replace them with a pointer to the
process structure itself.
Then we could have a shared signal structure that becomes responsible
for managing all signals received by the thread set. If it comes down
to it, it might actually be easiest to fork off a special thread just
to serve as a central gathering and handling point for signals. It
would probably be cleaner then trying to control access through a mutex
or token and such a thread would have a lot more flexibility in e.g.
dealing with SIGSTOP properly. This is an area that is really, really
messy in FreeBSD and we can do a lot better.
:>>5. A thread calls pthread_exit(), but userland does not if the thread
:>> memory can be reused because there is no flag indicated by kernel
:>> that the thread is exited, see FreeBSD's kse_exit() or thr_exit().
:>
:>
:> OK, I'll look at this. Can't this be handled inside the threading
:> library by adding the thread memory to a special free list?
:> Maybe even switching to a speical pthread_exit() stack and let
:> the thread free his own memory.
:
:The library indead has the special free list, but without a flag
:telling the memory can be reused, it is useless.
:Thread can not free its stack while it is using, and how to free
:special stack ? how about if different thread call pthread_exit at same
:time, multiple special stacks are needed, then how to free them ?
There are a ton of ways to deal with this issue but if we are going
to go to the trouble of creating a RF_CLONE for rfork, we can certainly
also supply a mechanism where the kernel can inform a management thread
that the exiting thread has indeed exited.
:> I don't like the LDT approach and GDT is even worse. What do you think
:> about a thread-local page mapping? It would be enough to satisfy the
:> needs of a 1:1 library and can be used to implement the support for
:> m:n as well. It doesn't suffer from the segment prefixing like it is
:> needed for the LDT approach.
:>
:Don't know how to implement thread-local page mapping, but TLB shutdown
:is worse than loading a segment descriptor.
A lot worse. At least I think it's a lot worse.
:>
:>>7. No __thread keyword style's tls support in rtld.
:>
:> Needs to be added.
:>
:> Joerg
You mean the idea of a 'thread local' global variable? This ought to
be fairly easy to add but I haven't researched making GCC generate
%gs: or equivalent prefixes on memory accesses, which is how we would
have to do it. The __thread keyword itself would have to emplace the
global in a special linker section (similar to what we do for module
lists and other things) but the hard part is making GCC generate the
proper access method if it doesn't already have an attribute to do it.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 6 之 24 篇)：