In message: <[email protected]> Hans Petter Selasky <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
