cvs commit: src/sys/kern kern_sig.c

[Nate Lawson]

David Xu wrote:
> David Schultz wrote:
> 
>> You have to worry about that anyway, though.  A and B need to know
>> that they're not allowed to hold locks across the calls if C calls
>> msleep(), for instance.  Anyway, your proposal if having a flag
>> for msleep() is basically the same as my proposal of having a
>> separate function.  (The only difference is that adding a separate
>> function doesn't break the ABI.)  So it sounds like we're more or
>> less in agreement here.
>>
>>  
>>
> This is not a lock problem, this is the problem why a stack variable can 
> not
> be used when thread is going to sleep, this is a rather odd behavior to me.
> For example,  thread A stack variable address p is put on a known place,
> e.g, a queue,  thread A unlocks the lock of the queue and sleeps,
> sometimes later, a producer thread B writes the data into memory pointed 
> by p,
> and wake up A, that's a very simple code, here malloc is not needed at all.
> At the time, kernel shoudn't swap out the thread stack, any code trying 
> to swap
> it out is totally broken.

I've always treated local variables as valid only within the current 
stack frame, from the current context.  If you had different per-context 
protection domains, for instance, there would be the same problem.

>>> First find all code written in such way, but it is not that easy.
>>
>> True.  If we changed msleep() to disable swapping by default, then
>> we wouldn't have to worry about correctness problems related to
>> missing some.

Or better, you could add a debugging option to _always_ emulate a swap 
on msleep by marking the page not present until msleep returns.  Then 
you wouldn't have to worry about correctness problems related to missing 
some.

-- 
Nate