On Fri, Nov 11, 2005 at 11:23:48AM +0900, YAMAMOTO Takashi wrote:
> > the SA code will put LWPs into LSSUSPENDED state also,
> > and I can't tell if those making those LWPs runnable
> > unexpectedly would cause other problems.
> 
> lwps holding VP, which kpsignal2() examines,
> can't get LSSUSPENDED without _lwp_* syscalls, afaik.

I meant in general, not just in kpsignal2().


> > a simpler way to avoid this problem would be to disallow
> > _lwp_suspend() and _lwp_continue() for SA processes.
> > there doesn't seem to be any value in allowing an application
> > to fight with the SA subsystem for control of LWPs.
> 
> are there any users of these syscalls at all? :-)

not in our tree.  I don't see why we ever would have any either.
(other than regression tests to make sure they work.)


> i guess that these syscalls and SA shouldn't share
> the same "suspended" state.

I'd rather just allow the SA code to assume that no one else is
messing with LWP scheduling state by disallowing these operations
that don't make any sense in an SA context anyway.  that way we
don't need to think about possible interactions when working on
the SA code in the future either.

-Chuck