DragonFly BSD
DragonFly commits List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: 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 ...


From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Tue, 1 Feb 2005 14:43:48 +0100
Mail-followup-to: commits@crater.dragonflybsd.org

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.

> 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.

> 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.

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

Needs to be added.

Joerg



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]