In article <20051111170354.GB6244@spathi.chuq.com>,
Chuck Silvers  <chuq@chuq.com> wrote:
>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.

This might be the case today, but we are going to be needing some
_lwp syscalls to control threads when PTHREAD_CONCURRENCY > 1. For
example how do you kill a thread that is running on a different
cpu without _lwp_kill()? I don't claim to understand how the virtual
processor handling is supposed to work, and it would be nice if someone
who did posted an explanation and a design document on how is all
this supposed to work with PTHREAD_CONCURRENCY > 1.

christos