RE: coroutines & timeout

[<wiffel@...>]

> > 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.

Basicaly, I added a time-out variable to the 'lua_State' of the
coroutine that - eventually - gets passed to 'luaV_execute' (the
main VM loop. If a state has such a time-out variable with a 
value bigger then 0, the time-out time is calculated and in 
every loop of the VM (that is between the execution of each
byte-code) the time is checked against the 'clock()'. If we're
after that time, the 'yield' behaviour is mimicked.

Besides this, I added some extra code to minimize the effect on 
the general performance of LUA (this is withing the main loop
of the VM, so every millisecond counts). So, in practise the
'clock' is not checked for 'non co-routine' code and only
checked every 512 loops of the VM. This reduces the performance
penalty to almoust 0. And I had to add some extra code to deal
with the absence of a result value in case of a time-out.

The negative parts of this implementation:
- primitve code (C-code) could  still block everything (but I 
  can live with that)
- Only checking after every 512 byte-code executions reduces
  the granularity of the possible time-out values. Right now
  it can go roughly op to 10 millisecons on my machine. Every
  time-out value below that will probalby only time-out after
  roughly 10 milliseconds.
 
> > 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 realy hacked into the code to see if it was at all possible. So,
I'm a bit reluctant (or should I say ashamed of myself) in releasing
this code into the big bad world :-) I'm willing to share it, if
you don't show it to your mother as a good piece of engineering :-)

Better would be for me to clean it up and releas it then, but before
doing that I would like to know if I'm not doing something that has
been done before, or if there is some better way in tackling this
thing. That was the main reason for my post.

> 
> 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!

I've been thinking about using explicit threads that time-out too.
It's feasable - with a bit of work - but the resulting code would
probably end up to be very platform dependend. And I like the fact
that the complete code-base of LUA hardly has any platform 
dependend code for the moment. That makkes it a lot easier to port
to many new platforms/devices. As an example, I'm looking at porting
it to an eZ80. It's very hard to port platform depend code to such
devices even for 'so called' multiplatform code. (Most of the time
people mean Windows/Linux/Mac if they are talking about 
multiplatform code) I'm already strugling with the io-library, since
the eZ80 doesn't have a filesystem. 

Next to that, I think that is not very wise to try to break out of
the VM-loop in the middle of byte-code execution. Doing so will open
up a whole new can of worms.

> Yours in curiousity,
> 
> Doug Rogers
> 

Wilfried Verachtert

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.644 / Virus Database: 412 - Release Date: 3/26/2004