Re: sigsetjmp & sigaction survey

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Fri Jan 29 1999 - 10:19:38 EST

 Edouard,

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.

Hmmm, did that break Solaris 5.x too?

        - 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