RE: Some findings (was Re: Design hole in nptl (and more general inPOSIX threads))

Hi, Dear Dragiša, what's the license of your code? I will send you mail offline.

-xiaofeng

-----Original Message-----
From: Dragiša Duric [mailto:[email protected]] 
Sent: Wednesday, December 31, 2003 4:59 AM
To: Li, Xiao Feng
Cc: [email protected]
Subject: Some findings (was Re: Design hole in nptl (and more general inPOSIX threads))

  Probably nobody who referred me to pthread_getattr_np for retrieving
of stack info ever tried it, as it does not work :). Not if I do not
give my stacks to my threads (in which case I do not need unportable
method to get that info back :) and I did not check that situation, as I
found portable workaround.

  This is what I did for my Modula-3 runtime. 

  As M3 thread creation is centralized, I've added bos (bottom of stack)
field to my Thread.T object and initialized it from my start_routine
from stack pointer at moment (address of some local variable).

  Next, I implemented PauseThread() signal handler (as was advised by
Jim Blandy and very similiar to Boehm GC technique) for SIG39 and there
I set tos (top of stack). SA_SIGINFO signal handler gave me registers in
ucontext and there is esp field. Modula-3 garbage collector is
conservative and it scans all registers and stack area of suspended
threads for maybe-a-traced-heap-reference.

  QUESTION: Can I sigqueue(2) a thread?

  Until I know answer to this, I am using pthread_self() or
pthread_getspecific() (this I prefer) inside my PauseThread() so I can
know where to put ucontext structure and whose tos field to set. If I
can sigqueue(2) a thread, I can pass identity information from outside
of signal handler and use only sem_post(3thr) for confirmation of
suspension, which is said to be async_safe.

  If someone is interested in details of implementation, source code can
be found at:

  http://home.rstel.net/~dragisha/gc-pthread

  dd

Дана чет, 18-12-2003 у 11:24, Li, Xiao Feng је написао:
> Um.. I think this proposal is reasonable. Stack scanning is essential
> for the performance of managed runtime systems, NPTL certainly can do
> better in this field before special hardware support is available.
> 
>  
> 
> -xiaofeng
> 
>  
> 
> Date: Wed, 17 Dec 2003 12:29:49+0000
> 
> From: Jamie Lokier <[email protected]>
> 
> To: Dragi?a Duri? <[email protected]>
> 
> Cc: [email protected]
> 
> Subject: Re: Design hole in nptl (and more general in POSIX threads)
> 
>  
> 
> Dragi?a Duri? wrote:
> 
> > Advanced (probably every) garbage collector needs to scan threads 
> 
> > stacks for pointers to traced heap being kept in local variable
> spaces 
> 
> > of procedures in suspended threads. While suspending of other
> threads 
> 
> > is possible in portable way (thanks to this list for help) it is not
> 
> > possible, in portable way, to get exact position of active portion
> of 
> 
> > threads stack. Only way (I know of) goes through
> pthread_getattr_np() 
> 
> > call which gives only partial information - one needs stack pointer 
> 
> > (obtainable only through oh-so-portable pthread debug interface and 
> 
> > only after hacking deeply nested include files for exact info on 
> 
> > position of stack pointer in greglist structure.
> 
>  
> 
> You can send a signal such as SIGUSR1 to all threads and have them
> record the stack pointer in a data structure before putting themselves
> to sleep.
> 
>  
> 
> > Meaning, it is not possible to implement this fundamental feature of
> 
> > advanced high-level langugages in portable way.
> 
> >
> 
> > Are there plans to fix this somewhere before greglist? :)
> 
>  
> 
> Well, no matter what changes are made to nptl, it's not going to make
> the solution portable to non-nptl platforms is it?
> 
>  
> 
> -- Jamie
> 
>