On Thu, Jun 28, 2007 at 01:45:56AM -0400, Jan Harkes wrote:
> 
> Make sure that it is actually using process.S, on some platforms we use
> makecontext/swapcontext macros from ucontext.h, I remember adding some
> tests in configure that check if those are available and whether they
> actually work correctly.
> 

OK, will do - though I have vague recollections of ucontext not being
available on NetBSD amd64

> Ah, yes lwp-2.2 had a problem on amd64 because makecontext was flipping
> the high bit on arguments passed to the thread created by makecontext.
> This was fixed in lwp-2.3 (CODA_USE_UCONTEXT should be undefined).
> 

Ah, I did notice that I was running lwp-2.2 but lwp-2.3 is available
in pkgsrc.  I will try building against that tonight.

> When we call savecontext the initial pointer should even get aligned on
> a 64-byte boundary (value of STACK_PAD in lwp_ucontext.c).
> 

I think what I will do is drop an assertion/fault into the code iff
the stack pointer is not correctly aligned so I can catch where the
problem starts - at the moment the damage is well and truly done by
the time the SIGBUS happens.

> 
> Pthreads used to be measurably slower (in micro benchmarks), not sure
> how much it slows down an actual client or server. The main problem I
> think was that everything else that links against lwp_pt needs to be
> compiled with CPPFLAGS+=-D_REENTRANT.
> 

I suspect that these days that this is less of a problem than it used
to be - multi-core machines are becoming a commodity item so
multi-threaded applications make more sense than they used to so the
frameworks are probably more tested/better supported than they were :)

-- 
Brett Lymn