RE: coroutines & timeout

[<wiffel@...>]

Hi,

Thanks for your reply.

> > For that, I realy need some kind of concurrent processes. The 
> > coroutines look nice (...) I don't need full fledged 
> 'threads' because 
> > that probably would involve using the threads of the 
> underlying OS. In 
> > my case, that would imply the installation of an OS on my embedded 
> > system and that's something I would like to avoid.
> 
> You can create an opcode counting hook and yield from there. 
> The problem with that is that the time taken up by a 
> particular number of opcodes can vary quite a bit. So it can 
> be extended by calling the hook very frequently and use it to 
> poll a timer, and only yield when that timer exceeds a set threshold.
> 
> Something as follows:
> 
> void opcodecounthook(lua_State *L, lua_Debug *ar) {
>     /* We can't yield across a metamethod/C-call boundary. */
>     if (L->nCcalls > 0) return;
>     /* See if more than the set threshold of time has passed 
> since the last yield */
>     if ((MilliSecs()-yield_last) < yield_threshold) return;
>     lua_yield(L, 0);
> }
> 
> The yield_last must be included as userstate with the lua 
> state, and set on resume as follows: yield_last=MilliSecs();

I guess that I did someting along these lines in my test, but
by hacking it in the VM-code directly. Your code looks a lot
cleaner!

I just started to look at LUA again since a few days, so I'm
not that familiar with the code for the moment. It looks -
from your explanation - that using 'userstate' and 'hooks'
are the prefered way in adding functionality - like the one
I'm asking - to the LUA VM. Is that correct?

Anyway, I'll spent some more time in reading the code,
some examples and the documentation before going on.
 
> For Lua code, this gives reasonably uniform cooperative time 
> slices. When the code being executed contains C calls that 
> take a long time to execute, latencies cannot be avoided 
> since C calls cannot be yielded. In particular this includes 
> pcall and other C library functions that take a function as 
> parameter. Also, coroutines cannot be used from within a resume.

These are the same limitations I'm encountering within my test,
but I can live with those.

I'm kind of curious about the 'coroutines cannot be used from
within a resume'. Maybe I'm just lucky, but the following 
example works as 'expected' in my test:

function aa()
  for i = 1, 1000 do
    print("aa")
--  coroutine.yield()
  end
end
co_aa = coroutine.create(aa)

function a ()
  for i = 1, 10 do
    print("a 1")
    coroutine.timedresume(co_aa, 1)
    print("a 2")
  end
end
co_a = coroutine.create(a)

coroutine.timedresume(co_a, 1000)

it outputs :

a 1
aa
aa
 .. a lot of 'aa's
aa
aa
a2
a 1
aa
aa
 .. a lot of 'aa's
aa
aa
a2
a1
a2

That's what I would expect. I'm I overlooking some kind of problem?
(Using the 'yield' works also, but gives another output of course)

> Albert-Jan
> 

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