Date: Wed, 02 Nov 2005 13:27:09 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: julian@elischer.org Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver Message-ID: <20051102.132709.101593999.imp@bsdimp.com> In-Reply-To: <43690EED.10703@elischer.org> References: <20051027.205250.55834228.imp@bsdimp.com> <43690424.1040904@alphaque.com> <43690EED.10703@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <43690EED.10703@elischer.org>
Julian Elischer <julian@elischer.org> writes:
: Dinesh Nair wrote:
:
: >
: >
: > On 10/28/05 10:52 M. Warner Losh said the following:
: >
: >> libc_r will block all other threads in the application while an ioctl
: >> executes. libpthread and libthr won't. I've had several bugs at work
: >
: >
: > so if the userland thread does an ioctl, and the the driver goes to
: > tsleep() when the ioctl is received, all other threads are also
: > blocked from executing, i.e wont be context switched to run ?
:
: in 4.x and earlier. a tsleep saves your spl level but re-enables the
: interrupts (from memory)
: when you re-awaken you are given your spl level again..
That's true, but irrelevant.
: All other threads are allowed to run.
That is not true.[*] *NO* other threads in your process run. Period.
None. Zero. Nada. Zilch. Your process is hung until the ioctl
returns. That's the fundamental problem with userland thread packages
such as libc_r.
I've had to work around this issue many times, and I'm 100% certain
that this is the case: sleep in an ioctl, and the entire process hangs
until the ioctl returns.
Warner
[*] Other processes on the system will run, true. Interrutps will
happen and run. But that's not what was being ask.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051102.132709.101593999.imp>