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

Re: Design hole in nptl (and more general in POSIX threads)



Дана сре, 17-12-2003 у 13:29, Jamie Lokier је написао:
> 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.

  As not every random programmer (/me for example) is
glibc-source-crunching character, I would be thankful if someone answers
next two questions:

  1. How do I bind signal handler for specific thread? Or process-wide
one is used, only in signaled thread context?

  2. Can I do sigwait(SIGCONT) for example, or sigwait(SIGUSR1) in
signal handler? Or solution is to send SIGSTOP to itself when I record
SP?

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

  Fast on irony, but slow on answer (hint, privmsg question ) ? :)

  Of course it is non-portable not because nptl, as I wrote in original
subject and message, but due do design of POSIX threads where C++
destructor mechanism was important enough to be taken into account
during design and advanced garbage collecting in compiled languages was
not. nptl did its best (and more, thanks to all involved) to be good and
rounded implementation.

> 
> -- Jamie
> 




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