From owner-cvs-src@FreeBSD.ORG Thu Mar 3 06:09:37 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D56F416A4CE; Thu, 3 Mar 2005 06:09:37 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C1F843D31; Thu, 3 Mar 2005 06:09:37 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-186-189.dsl.snfc21.pacbell.net [64.171.186.189]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j2369TZj018090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Mar 2005 22:09:35 -0800 Message-ID: <4226AA19.2080809@root.org> Date: Wed, 02 Mar 2005 22:09:29 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <200503021343.j22DhpQ3075008@repoman.freebsd.org> <200503020915.28512.jhb@FreeBSD.org> <4226446B.7020406@freebsd.org> <20050303033115.GA13174@VARK.MIT.EDU> <42269DB0.6070107@freebsd.org> <20050303052902.GA14011@VARK.MIT.EDU> <4226A46B.2090704@freebsd.org> In-Reply-To: <4226A46B.2090704@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@freebsd.org cc: David Schultz cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: John Baldwin Subject: Re: cvs commit: src/sys/kern kern_sig.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 06:09:38 -0000 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