On Wed, Apr 13, 2011 at 17:10, Fabio Mascarenhas <mascaren...@acm.org> wrote: > 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). Sorry, if I am to go for that much trouble for a task this simple, then I'm better to throw away WSAPI altogether and switch to lua-ev + lua-http-parser. >> 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... I posted about shutdown earlier — all I need is a way to terminate WSAPI loop from a handler. The rest is up to myself. > 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. What can be done with WSAPI (any one option will resolve my problem): 1. Fix signal handling (maybe can be done by fiddling with select(), maybe not). and / or 2. Allow user to replace socket.select() (or whatever WSAPI uses in dispatcher) with lua-ev loop. and / or 3. Allow user to specify extra socket / file handle / whatever to be put into dispatcher. and / or 4. Allow user to specify a timeout after which a custom handler would be called (copas does something like that). Thanks, Alexander. _______________________________________________ Kepler-Project mailing list Kepler-Project@lists.luaforge.net http://lists.luaforge.net/cgi-bin/mailman/listinfo/kepler-project http://www.keplerproject.org/
