Kris Kennaway wrote:
On Tue, Oct 14, 2003 at 08:17:27PM -0700, Kris Kennaway wrote:
On Wed, Oct 15, 2003 at 11:10:43AM +0800, David Xu wrote:
The change you made to ucontext.h breaks libkse. :-(
Speaking of libkse breakage:
10427 root 200 10500K 8380K kserel 6:44 0.0
< said:
> However, I can think of two situations under which it might have to
> be a system call:
I'm fairly certain I found a circumstance which required that it be
available to a system call, but I can't remember quite what it was.
(It was some other system call which could accept a ucontext_t
On Wed, Mar 22, 2000 at 02:48:24PM -0500, Daniel Eischen wrote:
> On Wed, 22 Mar 2000, Arun Sharma wrote:
>
> > On Wed, Mar 22, 2000 at 08:04:37AM -0500, Daniel Eischen wrote:
> > >
> > > I had them implemented and working for i386, and even had a hacked up
> > > libc_r that used them instead of
is going to use it to save and
restore thread state, we don't want the overhead of a system call.
The threads library doesn't _have_ to use ucontext, but both the
kernel and the threads library have to agree to some format (the
kernel has to pass register state out to the threads library wh
On Wed, Mar 22, 2000 at 08:04:37AM -0500, Daniel Eischen wrote:
>
> I had them implemented and working for i386, and even had a hacked up
> libc_r that used them instead of setjmp/longjmp. This was a few months
> ago under 4.0-current. At the time, I thought they'd be better off
> implemented a
On Tue, Mar 21, 2000 at 10:54:32PM -0800, Arun Sharma wrote:
> > > Before getting too far here, can we consider some other
> > > standard interfaces?
> > > #include
> > > int getcontext(ucontext_t *ucp);
> > > int setcontext(const ucontext_t *ucp);
> > > void makecontex
point where the discussion, altough meaningful and important,
> > has no direct impact on the sigset_t change. I agree with Peter that we
> > should as well consider the ucontext interface, but prefer to stay focussed
> > on changing sigset_t. So, here's where I shut up
> setjmp,longjmp,sigreturn,etc can all be done with this interface and it can
> > be used for libc_r and future kernel-assisted threading.
>
> We're at a point where the discussion, altough meaningful and important,
> has no direct impact on the sigset_t change. I agree with Pete
