[...]
The place where that could become a problem is if the task is itself
was allowed to directly use Lua's coroutines. Which, there are plenty of
valid cases where it might want to, for example it might use them for an
iteratior. But if inside one of those coroutines our "sys.sleep" or
whatever else is called, control will not be passed back to the main
task, because we're nested inside a different coroutine. That's the
problem I'm stuck on and the reason I started this thread.
The way I have designed my code is to add a non-blocking I/O class (userdata), which owns the file descriptor, and when you call the 'read' method you pass a callback function that is only called if no data is available (i.e. the operation would block). The function is called with the file descriptor and returns 'true' if the read should be retried, 'false' if you want the operation to fail. The code uses lua_callk to invoke the callback, it handles yields correctly, and yes, it's a bit painful to code this but it's definitely doable.
The advantage of this approach is that it keeps the details of coroutine management completely outside of my C code, and I can use different strategies for different Lua programs.
