Thomas De Schampheleire wrote:
Hi all,
I will try using the timeout() first, but I am wondering where I
should start the first invocation of my function.
Probably from attach().
-- Garrett
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]
<mailto:[EMAIL PROTECTED]>> wrote:
Paul Durrant wrote:
> On 4/25/07, Thomas De Schampheleire <[EMAIL PROTECTED]
<mailto:[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
