[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)

Dragiša Durić <dragisha ho com> writes:
> 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.
> 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? :)

You may find these helpful:


They are a work in progress, and are completely untested; I haven't
even compiled them yet.  (Hopefully I'll be able to do that in the
next few weeks.)  But there are extensive comments explaining how it's
supposed to work, which might give you some ideas.

The general approach to stopping threads is borrowed from the Boehm
GC, but this is a precise GC, and I have arranged the user's API so
that I don't need to intercept thread creation calls or do the other
strange things Boehm does.

It does depend on architecture-specific memory barrier functions;
POSIX doesn't include any functions that both synchronize memory and
are async-safe.

The "Minor C API" referred to in the comments is here, but you should
be able to make sense of threads.[ch] without reading it:


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