In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: Dinesh Nair wrote:
: >
: >
: > 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().
:
: Note that a thread can block on select/poll in 4.x and still allow other
: threads to run. I used this to solve a very similar problem to your in
: a 4.x app of mine. I have the app thread wait on select() on the device
: node for the driver. When the driver gets to a state when an ioctl
: won't block (like data being available to read), then it does the
: appropriate magic in it's d_poll method. select in userland sees this,
: allows the thread to resume running, and the thread then calls ioctl.
: Of course you have to be careful that you don't have multiple threads
: competing for the same data or that the data won't somehow disappear
: before the ioctl call runs. But it does work. Look at the aac(4)
: driver for my example of this.
Yes. If you have the ability to know that an ioctl won't block before
you call it, that would work too. This method is a little trickier,
like you say, but can be made to work. I've also seen ioctls that
were split into a 'foo_start' and 'foo_finish' pair (someimtes with a
non-blocking foo_status) to get around this restriction...
While ioctls generally cannot block, one can use these sorts of
techniques to avoid blocking. I'm glad that kernel threads are here
so we don't have to keep propigating these hacks...
Warner
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
