[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Coroutines & C boundaries
- From: David Given <dg@...>
- Date: Tue, 14 Feb 2006 10:23:28 +0000
> Your C code may need to use lua_resume rather than lua_call. Of course,
> then it needs to work in terms of coroutines rather than functions.
I did try making the scheduler itself a coroutine that the C code resumed; it
failed oddly, complaining that lua_resume() was trying to call a function
value. Looking at the code, it would appear that coroutine.create() does a
lot of stuff as well as calling lua_newthread(), and that the two might not
be strictly compatible.
I did try having a wrapper around the scheduler as follows:
scheduler = coroutine.create(schedule_now)
This allowed me to change my call to coroutine.yield() with a call to
coroutine.resume(scheduler). This avoided the C boundary error, but caused
all kinds of other weird stuff to happen.
How does yield() know where to transfer execution to? Does it go to the most
recent resume() that caused the current coroutine to be run?
> You may also be getting bitten somewhere by pcall being a C function. I
> suspect that this is the most common place where C code slips onto the
> stack unnoticed and if Lua 5.2 doesn't address the issue wholesale, I would
> hope that we could find a solution specifically for pcall.
Surely *all* Lua code gets run through a pcall, though? I really don't
understand what's going on here.
+- David Given --McQ-+ "The time has come," Mithrandir said, "To talk of
| email@example.com | many things: Of Moria, and bridges, and deep
| (firstname.lastname@example.org) | fissures --- of Balrogs, and their wings." ---
+- www.cowlark.com --+ Meneldil on rasfw
Description: PGP signature