cvs commit: src/sys/kern kern_sig.c

[Julian Elischer]

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.


this is why it is common kernel lore to not use the stack for anything that
is going to be visible outside the originating function. I guess the 
clause to be added to
the lore is that it shouldn't be used if you are calling down to a 
function that might
make it externally visible  as well.

>
>>>> The alternative, of course, is to just fix the code that assumes
>>>> that swapping doesn't exist.
>>>>
>>>>     
>>>
>>> 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.
>>
>>
>>  
>>