Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 03 Jul 2005 01:23:49 -0000
From:      David Schultz <das@FreeBSD.ORG>
To:        David Xu <davidxu@FreeBSD.ORG>
Cc:        cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, John Baldwin <jhb@FreeBSD.ORG>
Subject:   Re: cvs commit: src/sys/kern kern_sig.c
Message-ID:  <20050303060357.GA14180@VARK.MIT.EDU>
In-Reply-To: <4226A46B.2090704@freebsd.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 03, 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 not
> be used when thread is going to sleep, this is a rather odd behavior to me.
[...]

True, but my point is that there are *already* a bunch of rules
that have to be followed, so this is just one more.  All of the
rules that restrict what you can and can't call are bad for
modularity, and I agree that this one is particularly obnoxious.
Once again, that's why I suggested that the default be to have
msleep() disable swapping.  Then it could be selectively enabled
in a few places like the I/O path.

Of course, there's another possible solution which is to remove
the swapping code entirely.  That would certainly simplify things,
but it would also make FreeBSD degrade less gracefully under load.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303060357.GA14180>