cvs commit: src/sys/kern kern_sig.c
nate at root.org
Thu Mar 3 06:09:38 GMT 2005
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
> 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
More information about the cvs-src