On Thu, Jun 28, 2007 at 10:17:48AM +0930, Brett Lymn wrote:
> I had another look at the lwp process.S code and I can see a couple of
> problems.  1) the fp registers are not being saved on switch, 2) the
> stack is not 16 byte aligned.

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.

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

The second choice is to use sigaltstack to set up a new thread
(HAVE_SIGALTSTACK would be defined). Otherwise we fall back on the
savecontext assembly routines when creating the new thread. In both of
these cases we use setjmp/longjmp to perform the thread switches.

> The alignment is the real problem at the moment, moving data to/from
> the xmm registers apart from a few special instrcutions must be
> aligned on a 16 byte boundary.

Hmm, it is the hoard daemon thread which allocates 64KB stackspace and
I'm pretty sure it uses mmapped. So both the lower address as well as
the top of the stack should be 16-byte aligned.

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 will have a look at fixing lwp though I am wondering if it is not
> time to just layer lwp on top of pthreads (yes, I know this can be
> done - last time I looked I had problems) - I don't believe there is
> any modern OS that does not have a threading implementation these days.

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.

Jan