Date: Sun, 01 Feb 2009 14:08:15 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: hselasky@c2i.net Cc: freebsd-usb@freebsd.org, thompsa@freebsd.org Subject: Re: USB2 patches Message-ID: <20090201.140815.-1322632562.imp@bsdimp.com> In-Reply-To: <200902012200.11499.hselasky@c2i.net> References: <200902012031.56899.hselasky@c2i.net> <20090201195859.GH32503@citylink.fud.org.nz> <200902012200.11499.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200902012200.11499.hselasky@c2i.net>
Hans Petter Selasky <hselasky@c2i.net> writes:
: "2" is not an option. MPSAFETTY cannot sleep! And there is no IOCTL to drain
: the DTR command, if I'm not mistaken.
MPSAFETTY can sleep in the ioctl() context. It does hold the tty
lock, so when it wakes up it will know that the tty hasn't gone
away... The policy is please don't sleep, but it isn't totally
forbidden.
It would certainly be an option to queue the first one, note it is
pending in the softc and return, then block on subsequent ones until
the first one finishes achieving a delayed synchronous behavior and
avoiding the problems that you talked about. In this case, you avoid
the sleep when you can, and sleep when you can't.
But wouldn't the taskqueue run before the process that queued the
task? Shouldn't it have a higher priority? And can't you arrange the
taskqueue such that it processes 'modem state change queue' requests
and have the counter be the number of requests on the queue? then it
could do one at a time and you wouldn't have to worry about all
this...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090201.140815.-1322632562.imp>