cvs commit: src/lib/libthread_xu Makefile pthread.map src/lib/libthread_xu/arch Makefile.inc src/lib/libthread_xu/arch/alpha Makefile.inc src/lib/libthread_xu/arch/alpha/alpha pthread_md.c src/lib/libthread_xu/arch/alpha/include pthread_md.h src/lib/libthread_xu/arch/amd64 ...

[David Xu]

Joerg Sonnenberger wrote:
On Tue, Feb 01, 2005 at 09:03:31PM +0800, davidxu wrote:

There are still some serious problems, most because missing kernel
features to support 1:1 threading, problems:
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.

3. A crashed thread should bring down whole process, but it is not.


Same as (2).


4. A thread calls exit() should remove other threads in same process,
  but it is not, there should a syscall to exit a single thread
  or a whole process.


Similiar to (2).


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 ?


6. There is no kernel interface to manage TLS descriptor, either use
  GDT or LDT, but there is no allocation code in kernel which can
  resolve confliction among libraries using LDT at same time.


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.

7. No __thread keyword style's tls support in rtld.


Needs to be added.

Joerg