Date: Thu, 14 Sep 2000 12:44:56 +0400 From: "Valeriy E. Ushakov" <uwe@ptc.spbu.ru> To: FreeBSD Java Mailinglist <freebsd-java@FreeBSD.ORG> Subject: Re: Threads questions Message-ID: <20000914124456.A24487@snark.ptc.spbu.ru> In-Reply-To: <Pine.BSF.4.21.0009132210060.403-100000@picnic.chuckr.org>; from "Chuck Robey" on Wed, Sep 13, 2000 at 22:15:15 References: <200009122153.PAA25042@nomad.yogotech.com> <Pine.BSF.4.21.0009132210060.403-100000@picnic.chuckr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 13, 2000 at 22:15:15 -0400, Chuck Robey wrote:
> > If the OS supports kernel threads, then these provide the get/setcontext
> > functions for this, but since none of the *BSD's support them, we don't
> > have the library functions.
>
> I just did some porting of a homemade threading package from FreeBSD to
> Solaris, where they *do* have ucontext.h, and the {get|set|make}context
> calls. From my architectural reading, that's because (on Sparc
> processors) getting the stack & registers doesn't get you the full
> execution context (you need registers from windows that are currently
> invisible, since return addresses are kept in registers, not on the
> stack).
It's easy to flush register windows to stack:
asm volatile("t %0" : : "n" (T_FLUSHWIN));
and signal trampoline code for BSD/sparc (written by Chris Torek for
his original port and still here) has a clever hack to compensate for
lack of ucontext somewhat - in the trampoline it saves g's to l's of
the trampoline window - and thus in the signal handler you can access
all the 32 registers (at the time of signal) by peeking at the two
frames below the signal handler frame.
SY, Uwe
--
uwe@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000914124456.A24487>