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. Paul -- Paul Durrant http://www.linkedin.com/in/pdurrant _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
