Hi all,
I will try using the timeout() first, but I am wondering where I should
start the first invocation of my function.
The code I would like to run could be considered to be related to power
management. Is there a certain file or function from where I should call my
function? For this start, should I use a taskq then?
Thank you,
Thomas
On 4/25/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
Paul Durrant wrote:
> On 4/25/07, Thomas De Schampheleire <[EMAIL PROTECTED]> wrote:
>>
>> If I would use timeout only to start function A, and within function
>> A do a
>> new call to timeout in order to keep it running each period, that
>> would the
>> bad thing to do, right? Since then I would leave a trail of unfinished
>> functions behind...
>>
>
> No. timeout() does not block until the background task is completed
> (that would kind of defeat the point) so there's no unfinished
> functions. Self re-scheduling timeouts are quite common. The tricky
> part comes when you want to stop such a thing as you cannot hold a
> lock over untimeout() which you also hold in your background function.
>
>> Does the following strategy then work?
>> In function A, call timeout with function B as argument
>> In function B, first schedule a taskq that will run A, then do the
>> necessary
>> things that are needed
>>
>> Is it correct that in this way, since the scheduling the new taskq is
>> the
>> first thing that is done, the actual time between invocations of the
>> code is
>> quasi constant, i.e. does not depend on how long the actual code
>> within B
>> takes?
>>
>
> Given what I said above this is unecessarily complex. I believe it is
> ok to schedule a task on a task from within a task handler, so you
> should be able to use taskqs or timeout to achieve what you want but
> using both is unnecessary.
timeout handlers have to adhere to interrupt service routine
constraints. (I.e. they generally should be short lived, should avoid
blocking, and can only use mutexes initialized with an appropriate
iblock cookie. Note that while the code will _work_ if you don't
adhere to these constraints ... due to the way timeout is implemented
... it isn't DDI compliant and isn't guaranteed to work in the future.)
Conversely, taskq's offer no reasonable clock-based scheduling
mechanism. Using delay() inside a taskq thread will block DDI
suspend/resume (and therefore also certain kinds of Dynamic
Reconfiguration.)
The upshot is, for certain kinds of tasks, you really do need to use
both taskq's and timeouts.
-- Garrett
>
> Paul
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
