Re: Coroutines & C boundaries

[David Given <dg@...>]

[...]
> 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:

local scheduler
function schedule_wrapper()
	scheduler = coroutine.create(schedule_now)
	coroutine.resume(scheduler)
end

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
|  dg@cowlark.com    | many things: Of Moria, and bridges, and deep
| (dg@tao-group.com) | fissures --- of Balrogs, and their wings." ---
+- www.cowlark.com --+ Meneldil on rasfw

Attachment: pgpRbrEwVzuIb.pgp
Description: PGP signature