[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Throwing an error on a yielded thread
- From: esmil@...
- Date: Fri, 5 Dec 2008 01:06:45 +0100 (CET)
"Sam Roberts" <firstname.lastname@example.org> writes:
> On Wed, Dec 3, 2008 at 3:17 AM, <email@example.com> wrote:
> > Another option is to have some Lua code wrap all the C callbacks that
> > might yield in an assert()-like function (or assert() itself) that
> This is the essence of my suggestion. Of course you wouldn't litter
> your code with raw calls to assert and coroutine.yield() as in my
> example, you'd factor them into some nice functions so users or your
> APIs would have the mechanics hidden from them.
> > calls errors on some magic input, before any script is run. This
> > just seems like a very inefficent and awkward solution to me.
> Not sure what do you mean by inefficient? Wrapping calls that might
> return nil, possibly because they were resumed, in an assert is pretty
> Also, since you can't yield across C function calls, there's no
> particular reason to not always do the yielding in the lua code that
> wraps your C code. Its cleaner, in a way, since it allows you to test
> your C bindings independently from the use of coroutines.
> This technique is demonstrated:
> Note that the underlying C API (connection:receive()) doesn't yield,
> the yield behaviour is implemented in lua on top of it, seperating the
I guess you're right. Moving more of the multiplexing code to Lua itself
might not be such a bad idea. At least it would make the job of coding
the C side easier as you say. You've definately given me something to