RE: wrapping multithreaded C code in a library

["Thijs Schreijer" <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org]
> On Behalf Of Javier Guerra Giraldez
> Sent: zaterdag 8 oktober 2011 13:15
> To: Lua mailing list
> Subject: Re: wrapping multithreaded C code in a library
> 
> On Fri, Oct 7, 2011 at 5:38 PM, Thijs Schreijer
> <thijs@thijsschreijer.nl> wrote:
> > I’m in a project where I have a server config (luasockets, copas,
> etc), but
> > also need to use an external library that uses a lot of async
> > calls/multithreading/callbacks. How would I get the callbacks back
> into lua
> > (running on the interpreter, not embedded) without running into
> thread
> > issues?
> 
> if you're not set on your design of multiple threads driving the Lua
> code, you might consider my Helper Threads Toolkit, where a single
> coroutine-driven Lua code drives several C tasks running on several
> threads [1].
Reviewed it, looks like a possible solution for dispatching work to some C routines. But how would this handle callbacks from external events? Eg. The thread doing the callback was not initiated from Lua, hence there is no corresponding lua thread that can be resumed. Can this be handled to?

> if you already decided on several threads interacting with a LuaSocket
> loop, i'd say that your idea is workable; except that I'd replace the
> TCP packet with an event on another kind of socket.  In POSIX systems,
> you can create a socketpair, or a pipe.  On Linux, there's and
> eventfd, BSD have a similar thing.  All these are file-like objects,
> handled by a filedescriptor, and you can wait on signals there with
> the classic select() call, the same used by LuaSocket.
I'm on windows, so didn't know this. As deployment will probably be linux this might be a good pick. Pitty about losing platform independence though.