setcontext syscall

setcontext syscall

[George Fankhauser]

Hi there!

I wonder why linux i386 does not implement setcontext as a syscall. 
Instead it's in in glibc in userspace.

The problem that one may run into is with asynchronous signals such as 
SIGALRM, VTALRM, and IO: Let's say you have good reason to block such 
signals because your handling one of them and want to restore another 
user context which has them enabled in its sigmask. What sigcontext 
simply does is
1. trap into sigprocmask
2. restore all regs and jump
after exit of 1) until jump in 2) there is plenty of time to run into 
another asynchronous signal which must be detected in the nested handler 
etc. This is rather ugly.
I see this as a main reason to put setcontext into the kernel. Another 
one is performance: since we use sigprocmask, a syscall is used anyway.
And BTW: All SysV implementations use indeed syscalls for set/getcontext 
for these reasons.

What do you think?

regards
George
-- 
Sensaco GmbH
mailto:gfa@sensaco.com

Re: setcontext syscall

[Benjamin Herrenschmidt]

On Thu, 2003-11-20 at 18:03, George Fankhauser wrote:
> Hi there!
> 
> I wonder why linux i386 does not implement setcontext as a syscall. 
> Instead it's in in glibc in userspace.

On ppc32, we have started doing just that, a syscall called
sys_swapcontext that does all the variations of get/set_context.
We'll do as well on ppc64 soon.

It also helps perfs because on ppc, the kernel actually knows if
things like the FPU or the Altivec unit were ever used by the
process, and so if it's worth saving/restoring those registers
as part of the context.

Ben.