Date: Wed, 02 Nov 2005 14:17:38 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: dinesh@alphaque.com Cc: freebsd-hackers@freebsd.org Subject: Re: locking in a device driver Message-ID: <20051102.141738.43008707.imp@bsdimp.com> In-Reply-To: <43692719.90805@alphaque.com> References: <43690424.1040904@alphaque.com> <20051102.121248.74711520.imp@bsdimp.com> <43692719.90805@alphaque.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <43692719.90805@alphaque.com>
Dinesh Nair <dinesh@alphaque.com> writes:
:
:
: On 11/03/05 03:12 Warner Losh said the following:
: > 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.
:
: looks like i've got a lot of work to do, poring thru all the ioctls for the
: device and trying to use another method to wait instead of tsleep().
If you have to run on 4.x, that may be the case. The other way around
this is to create a helper program that gets the ioctl request over a
pipe or socket, does the call to the kernel and then returns the
results. Not idea, I'll grant, but it is an alternative worth
thinking about if the number of ioctls is large and the impact of
conversion to read/write channels is big.
: > works. If you use libc_r on 5, you'll see exactly this behavior. If
: > you use libpthread or libthr, you won't.
:
: i use gcc -pthread, so it's libc_r on 4.x. what does 'gcc -pthread' link to
: on 5.x ?
libpthread by default, others if you use libmap.conf
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051102.141738.43008707.imp>