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
