RE: coroutines & timeout

["Bilyk, Alex" <ABilyk@...>]

I would think in general this is not such a hot idea for Lua. For instance, this will not work in the middle of a function called under pcall or a metatable. Thus there is no way to enforce it to begin with. On the other hand it is hard to imagine the usefullness of this accross the board as it seems from my experience the scripts want to yield in a particular spot, rather than with a given time regularity in the middle of nowhere (imagine driving animation, simulation, state machine, a slide show, etc. for instance). All of them will need yilding occur in some orderly fashion in places dictated by logic rather than time. Using the debug hooks for yeilding have caused more problems for us than it solved as it had been highly unreliable from my experience (this may change in the future)... opcode hooks are especially prone to nasty side effects/bugs when yielded from (at least they were a year or so ago). Line hooks have also suffered from similar dificiencies but to a lesser degree.

I use a number sleep functions in my scheduler and people use them where/how they see fit in their scripts. And we have non-programming staff using Lua on a daily basis with no complaines about this particular aspect of it.

Just my .02
Alex

>-----Original Message-----
>From: Doug Rogers [mailto:rogers@innocon.com]
>Sent: Wednesday, April 14, 2004 4:49 AM
>To: Lua list
>Subject: Re: coroutines & timeout
>
>
>On Tuesday 13 April 2004 17:13, wiffel@yucom.be wrote:
>
>> I would be happy with a version of 'coroutine.resume' that 
>can time-out.
>
>I'm curious how that would be implemented without building a 
>threading library 
>into the VM. I, too, would be very happy to have that sort of behavior 
>available for my embedded work.
>
>> As a test I fooled around in the VM and hacked a bit around to see if
>> such a construct is at all possible. I added a primitive called
>> 'coroutine.timedresume' that behaves as the 
>'coroutine.resume' but takes
>> as it's second parameter a number which represents the milliseconds
>> after which a 'yield' should be 'forced'.
>
>Do you happen to have a patch of that change? I'd love to 
>check it out. What 
>do you do with the (not-fast-enough-) yielding code? What 
>mechanism do you 
>use to stop that code? I suppose a better understanding of the 
>VM on my part 
>- and a copy of your patch! - would help me.
>
>I think using an absolute timeout, like pthread_cond_timedwait(), is 
>preferable. Of course that requires a standard monotonic time 
>source. Or 
>perhaps provide for both absolute and relative times; something like 
>coroutine.resumeuntil and coroutine.resumeduration.
>
>One of the things that bugs me about the use of timespecs in C 
>is that the 
>POSIX clock_gettime() is NOT monotonic - it is allowed to 
>follow the system 
>time, which can be set from outside the running program. That 
>means that 
>either the realtime code must manage the changes reasonably or 
>that it must 
>use a separate clock. In our case, we just never set the time 
>on our system. 
>It's typically January 1970 whenever you ask it!
>
>Yours in curiousity,
>
>Doug Rogers
>
>
>