>Garrett D'Amore wrote:
>> Thomas De Schampheleire wrote:
>>> Hi,
>>>
>>> The timeout(9F) manpage says:
>>>
>>> "The function called by timeout() must adhere to the same
>>> restrictions as a driver soft interrupt handler.
>>>
>>> The function called by timeout() is run in interrupt context
>>> and must not sleep or call other functions that might sleep."
>>>
>>> Does this mean that a function which is called using a timeout, cannot
>>> use mutex_enter() ?
>>
>> No. But you should not call cv_wait, or its brethren.
>>
>> You should not attempt to acquire a lock which will be held by other
>> functions calling cv_wait, or its brethren. (There are ways to do
>> that safely, but it requires a fair bit of effort to make sure you do
>> it safely.)
>>
>Maybe above statements could be added in the man page?
>Since timeout is a public API, new driver developers might run into this
>situation without knowing the constraint of timeout API. At least, as a
>QE engineer, I have encountered this situation before. Maybe it's worth
>filing a bug against man page for timeout(9F).
But it is documented in the manual page:
The timeout() function schedules the specified function to
be called after a specified time interval. The exact time
interval over which the timeout takes effect cannot be
guaranteed, but the value given is a close approximation.
The function called by timeout() must adhere to the same
restrictions as a driver soft interrupt handler.
The delay(9F) function calls timeout(). Because timeout() is
subject to priority inversion, drivers waiting on behalf of
processes with real-time constraints should use
cv_timedwait(9F) rather than delay().
There's a lot more information in the soft interrupt manual page
(ddi_add_softintr)
Casper
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
