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

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Tue, Feb 01, 2005 at 10:09:39PM +0800, David Xu wrote:
> >>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.

I have to read the SUS requirements, but I'm pretty sure it is
not that difficult. The question is wether we want to fully
abstract the signal group concept and have a signal group
(identified by the current pid) for each process in the
original sense.

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

I have to figure out the details and I'll look at the FreeBSD code too.

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

We have to touch the page tables for a process switch anyway, it's not
that expensive to have a thread-local page mapping there I think.
On the other hand the LDT approach costs for every access.

Joerg