Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Nov 2005 12:12:48 -0700 (MST)
From:      Warner Losh <imp@bsdimp.com>
To:        dinesh@alphaque.com
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: locking in a device driver
Message-ID:  <20051102.121248.74711520.imp@bsdimp.com>
In-Reply-To: <43690424.1040904@alphaque.com>
References:  <4361044B.50807@alphaque.com> <20051027.205250.55834228.imp@bsdimp.com> <43690424.1040904@alphaque.com>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Dinesh Nair <dinesh@alphaque.com>
Subject: Re: locking in a device driver
Date: Thu, 03 Nov 2005 02:23:32 +0800

> 
> 
> 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 ?

Yes.  if you tsleep with signals enabled, the periodic timer will go
off, and you'll return early.  This typically isn't what you want
either.

> is this behaviour only 4.x specific or is it also there in 5.x ?

This behavior is libc_r specific.  Any userland threadding library
will have these issues.  It is fundamental to how userland threadding
works.  If you use libc_r on 5, you'll see exactly this behavior.  If
you use libpthread or libthr, you won't.

Warner



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