Re: cvs commit: src/lib/libthread_xu Makefile pthread.map src/li

看板DFBSD_commit作者時間21年前 (2005/02/02 02:01), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串3/24 (看更多)
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
文章代碼(AID): #11_yGF00 (DFBSD_commit)
討論串 (同標題文章)
完整討論串 (本文為第 3 之 24 篇):
文章代碼(AID): #11_yGF00 (DFBSD_commit)