On Wed, Apr 13, 2011 at 9:03 AM, Alexander Gladysh <aglad...@gmail.com> wrote: >> In an ideal world all Lua I/O would be handled by the same scheduler, >> so you could block on a read from the FCGI pipe and still receive >> signals, or other events. But you can still use one of the thread >> libraries (Lanes, or the one that Robert of this thread just released, >> I am sure there are others) to spawn a thread that just waits and >> responds on signals (lather, rinse, repeat for other kinds of events >> that cannot wait). > > Um. Did you just suggest to reuse the same state from two threads? > > If not, then how would I release the log file?
These thread libraries create new Lua states. You basically move logging to a separate "process" (in the Erlang definition of process), when you want to log something send a message to this process using whatever communication method the thread library uses (Lanes has one, Robert's favors ZMQ). Your logging process selects on both logging events from your application, and notifications that the log has been rotated (signals, or inotify). > > Nevertheless, I believe that my question is legitimate and my use-case > is not too-exotic. It should be supported by WSAPI somehow. > In your other message: > It will probably resolve the concrete problem with the log file, but > will not help the problem in general. I do need to be able to send a > message to a particular WSAPI fork and receive an immediate answer. >From the point of view of the WSAPI app, how would this support look like? In the logging example, a Lanes/lua-llthreads/LuaSignal solution can be abstracted away behind a logger object. Shutdown is harder, and a solution will depend on what kind of resources you need to free, but I have trouble seeing how WSAPI itself could make it easier, given what stock Lua makes you work with... for general event handling WSAPI would need to force you to use one of the existing threading libraries, or go the node.js route and rewrite everything I/O to play nicely with a coroutine scheduler that would be a kind of copas on steroids, using a mix of libevent and worker threads. > Alexander. > -- Fabio Mascarenhas _______________________________________________ Kepler-Project mailing list Kepler-Project@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project http://www.keplerproject.org/
