Re: [RFC][PATCH] _UC_TLSBASE for all ports

[David Holland <dholland-tech%netbsd.org@localhost>]

On Fri, Aug 10, 2012 at 08:00:32PM +0200, Emmanuel Dreyfus wrote:
 > > if you start using using another thread's stack, you are assuming
 > > the identity of that thread.
 > 
 > It is some part of its identity, but not all. [...]
 > 
 > I just propose to add an option to avoid that. I have trouble to
 > understand why it meets such a resistance, since most of our ports
 > already have that option available. I just add missing bits.

This discussion would benefit from some broader context.

(1) What is the C&V of the pertinent standards that describe
setcontext and getcontext?

(2) What is the ostensible point of programming with setcontext and
getcontext?

(3) What (possibly misguided, possibly not) things is glusterfs
actually attempting to do by mucking with setcontext and getcontext in
the way it is?

Only by addressing the complete picture can we reasonably expect to
decide on a semantically sound interface that we won't regret in the
future.

Now, ISTM that the underlying purpose of getcontext and setcontext was
always to allow writing simple userlevel-only thread systems without
needing MD assembler for context handling. If this is in fact the
case, the most reasonable use of these functions in conjunction with
pthreads is to implement an N-on-M thread system, and they should be
designed accordingly. ISTM therefore that it should be possible to
migrate private threads (instances of the N) between kernel threads
(instances of M), just as it's possible to migrate in-kernel lwps from
one processor to another. However, it may not be possible to structure
this in a sane manner given the available interface. Or the premises
of this paragraph may be wrong.

-- 
David A. Holland
dholland%netbsd.org@localhost