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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:...
:>>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@xxxxxxxxxxxxx>