First draft: rewrite of {get|set|swap}context(3)

Daniel Eischen eischen at vigrid.com
Sun Aug 17 20:12:35 PDT 2003


yOn Mon, 18 Aug 2003, David Xu wrote:

> On Monday 18 August 2003 02:50, Marcel Moolenaar wrote:
> > Gang,
> >
> > Please review the attached patch and let me know to what extend it
> > introduces breakages. It is the result of "aggressive engineering"
> > to provoke comments and further fuel discussion. The reason for this
> > approach is that we currently do not initialize any fields other than
> > the mcontext and sigmask and only partially copyin() and copyout()
> > the contexts (typically only the mcontext and sigmask fields). This
> > generally is very sensitive to breakages, especially when we intro-
> > duce flags or need to use any of the spare fields.
> >
> > getcontext(3): the whole ucontext is zeroed before (partially) filled
> > 	and we copyout() all of it. This means that uc_link can only
> > 	be set/defined after calling setcontext().
> > setcontext(3): we copyin() the whole ucontext but partially restore
> > 	its fields. The sigmask is restored conditionally based upon
> > 	the UCF_SIGMASK flag.
> > swapcontext(3): we preserve uc_link by doing a partial copyin(). The
> > 	context is otherwise zeroed and partially filled. we copyout()
> > 	the whole context.
> >
> > The patch has only been compile-tested.
> >
> > Shoot...
> 
> Then doesn't signal context in signal handler have a UCF_SIGMASK ?
> 
> void    (*__sa_sigaction)(int, struct __siginfo *, ucontext_t *ucp);
> the context *ucp should have UCF_SIGMASK now.
> I think it should be UCF_NOSIGMASK. But for libkse, we really needn't

I think so too.

> this kind of hack, because M:N thread in kernel always masks all signals,
> you can always SIGFILLSET(&uc.uc_sigmask) before call set_context.

That works for M:N, but not when THR_GETCONTEXT() (and perhaps
someday THR_SETCONTEXT()) is used for a scope system thread.
Hmm, this wouldn't seem to result in a context that needs to
be restored by the syscall though.

-- 
Dan Eischen



More information about the freebsd-threads mailing list