Date: Thu, 25 May 2006 23:59:34 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: gurney_j@resnet.uoregon.edu Cc: cvs-src@freebsd.org, scottl@samsco.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/syscons/apm apm_saver.c src/sys/i386/bios apm.c apm.h Message-ID: <20060525.235934.-1956306548.imp@bsdimp.com> In-Reply-To: <20060526055424.GG49081@funkthat.com> References: <44766F75.9060100@samsco.org> <20060525.220611.74708877.imp@bsdimp.com> <20060526055424.GG49081@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20060526055424.GG49081@funkthat.com>
John-Mark Gurney <gurney_j@resnet.uoregon.edu> writes:
: Warner Losh wrote this message on Thu, May 25, 2006 at 22:06 -0600:
: > > In the past, I've been against mandating that callouts/timeouts/generic
: > > taskqueues should not be allowed to sleep. However, after looking over
: > > the history of this problem as well as others, it seems that it's just
: > > too easy for driver authors to make bad assumptions and wind up with a
: > > priority inversion/deadlock like this. It would be relatively trivial
: > > to mark these contexts as being non-sleepable and have the msleep code
: > > enforce it, like is done with ithreads. What do you think? Anyways,
: > > thanks for looking at this and fixing it.
: >
: > At the very least, we should mandate that timeouts are a non-sleepable
: > event. Sleeping just doesn't work there. taskqueues, I'm less sure
: > of, since short sleeps there work, but do degrade performance. I like
: > this idea.
:
: People worried about things like this should create their own thread
: for their taskqueue.. It's quite easy (simple macro declaration), and
: I did that for handling kq in kq...
The problem isn't people that are worried about these things... It is
those that don't worry about them..
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060525.235934.-1956306548.imp>