RE: sigsetjmp & sigaction survey

Date view Thread view Subject view Author view

From: Parmelan, Edouard (EP510777@exchange.FRANCE.NCR.com)
Date: Fri Jan 29 1999 - 09:14:55 EST

Hi,

for SVR4 with getcontext(), makecontext() and swapcontext()

#include <ucontext.h>

        ucontext_t newCtx;

        /* retreive current context */
        getcontext(&newCtx);
        
        /* setup new stack */
        newCtx.uc_stack.ss_size = stack size;
        newCtx.uc_stack.ss_sp = ALLOC(stack size);
        newCtx.uc_stack.ss_flags = 0;

        /* reinitialize context with new stack and more */
        makecontext(&newCtx, func, 0);

...

        /* context switch */
        swapcontext(&lastThread->context, &currentJThread->context);

        
That all.

Hope this help,
Edouard.

> -----Original Message-----
> From: Parmelan, Edouard
> Sent: Friday, January 29, 1999 2:37 PM
> To: 'Godmar Back'
> Cc: 'kaffe-core@rufus.w3.org'
> Subject: RE: sigsetjmp & sigaction survey
>
> Godmar,
>
> I just test new jthread with sigsetjmp/siglongjmp and
> it fail on NCR MP-RAS :(
>
> 1. SP_OFFSET is not the same for jmp_buf and sigjmp_buf
> 2. sigsetjmp and siglongjmp are in fact getcontext() and
> setcontext(). These two system calls use an ucontext_t
> as parameter.
>
> I change SP_OFFSET to point to ucontext->mc_ucontext.greg[SP],
> the STACK_COPY don't SEGV, good. But reschedule() fails with
> the assert (lastThread == currentJThread), not good :(
>
> It seems that changing the value of SP in an ucontext don't
> work :(
>
> I think that jthread_create() should use an helper function
> (aka in assembler language) that changes the stack, calls sigsetjmp()
> in that new stack, and finaly restores the original stack.
>
> With this behavior, jthread don't need any more the glue of SP_OFFSET
> as the sigjmpbuf will save the context of the new stack.
>
>
> Bad news for my last message from NCR :(
>
> Remember, don't send comments to address @...France.NCR.COM,
> I'll leaving my job at NCR France in about three hours :)
>
> Edouard.
>
> > -----Original Message-----
> > From: Parmelan, Edouard
> > Sent: Thursday, January 28, 1999 7:09 PM
> > To: 'kaffe@rufus.w3.org'
> > Subject: RE: sigsetjmp & sigaction survey
> >
> > Godmar,
> >
> > > Two questions:
> > >
> > > 1. Is anybody using kaffe on a system that does not have
sigsetjmp/siglongjmp?
> > NCR MP-RAS have sigsetjmp/siglongjmp
> > >
> > > 2. Is anybody using kaffe on a system that does not support sigaction?
> > NCR MP-RAS have sigaction
> >
> > > The reason I'm asking is because Pat wrote an optimized version of
> > > jthreads that uses sigsetjmp and avoids saving the signal state in
many
> > > cases where we switch threads. On FreeBSD, this cuts thread switching

> > > time from 1400 to 450 cycles, and we may be able to go down to 180
cycles,
> > > as measured from Java.
> > Magic :)
> >
> > > Now why we would optimize thread switching when the rest of kaffe
> > > still sucks so much, don't ask. The answer is: research.
> > The answer is: better kaffe
> >
> > Edouard.

Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:53 EDT