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 - 11:38:58 EST

Godmar,

> which solution do you prefer:
> switching to the *context functions or using #ifdef for sigsetjmp
> or setjmp? In the latter case, we'd probably define a machine-dependent
> macro SETJMP or some such.
I'm trying with CONTEXT_INITIALIZE(JTID) and CONTEXT_SWITCH()
macros.

CONTEXT_SWITCH(LAST, CURRENT) \
        swapcontext(&(LAST)->env, &(CURRENT)->env)

CONTEXT_INITIALIZE(JTID) do { \
        jthread *jtid = (JTDI); \
        ucontext_t *uc = &jtid->env; \
        sigaltstack(NULL, NULL); \
        getcontext(uc); \
        uc->uc_stack.ss_sp = jtid->stackBase; \
        uc->uc_stack.ss_size = jtid->stackEnd - jtid->stackBase; \
        uc->uc_stack.ss_flags = 0; \
        makecontext(uc, start_this_sucker_on_a_new_frame, 0); \
} while(0)

jthread_create() became:
#if defined( CONTEXT_INITALIZE )
        CONTEXT_INITIALIZE(jtid)
#else
        if (sigsetjmp(jtid->end, false) == 0)
...

#endif
        resumeThread(jtid);

I need an other macro for the type of jtid->env
but as it's the same for me, I try without that.

But it fail :(

Edouard.
> Hmmm, did that break Solaris 5.x too?
I don't know
>
> - Godmar
>
> >
> > 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