On Mar 31, 2008, at 8:12 PM, Graham Wakefield wrote: I solved the problem (see the other posts). It was my fault On Mar 31, 2008, at 3:56 AM, Eugen-Andrei Gavriloaie wrote: To further summarize the problem:
1. Have a c++ working thread that gets it's work chunk from a queue 2. Wrap all the internals in a c++ function callable from Lua a. enqueue the work chunk b. yield Lua c. wait for the results from thread (we will get signaled) d. resume Lua by invoking lua_resume 3. The writer of the Lua script must not know anything about the internals of the call (we must not force him to make a yield/resume from Lua)
Are you wanting to use multiple OS threads to achieve this? Lua doesn't support multi-threading by default, and enabling it through the lua_lock macros may impact performance considerably. BUT, there's nothing stopping you having Lua in a single OS thread, spawning multiple OS threads and waiting for them to return. A good example is http://helper-threads.luaforge.net/
No, I don't want to use multiple threads. Only for time consuming functions. But those functions will not have anything to do with Lua. In fact, all the server is single threaded (accepting connections, serialize/deserialize messages, invoking Lua function upon messages receive, etc). If one user wants to have access to the database, he will put a message in a special queue. The working threads will pick the work load from there, process it and put the results in another queue. last operation that a thread is doing is to signal "job completed" to the main thread who in turn picks up the result from the queue and do whatever there is to do with it. Including resume a yielded lua_State. So, the Lua script writer doesn't have to know anything about the internals of the database layer. All he has to know is the type and connecting string to the database. And, of course, to write the SQL in that particular dialect of SQL.
Some inside information :)
Is a RTMP server written entirely in c++ with applications written by the final user in Lua. The server is using kqueue for networking but not only for that. Thread signaling is made using pipes that in turn are managed by kqueue. Very clean design that is offering robustness since we don't do and shared resource protection (no more race conditions).
I've chosen Lua for scripting RTMP applications because:
-- very light-weight -- powerful -- small memory footprint -- offers built in notion of "session" through coroutines (adopting python for this, was a disaster!!!) -- incredibly easy syntax. I've started to learn Lua syntax. But soon I just found out that I already know Lua :). So any technical guy can learn it in a matter of hours. (Or find out that he already knows Lua :) ) -- ability to load external libraries. Of course, python has this too, but try to make an wrapper for python without swig (the horror! the horror!). Not to mention that having that *.py generated by swig was stepping on my bare nerves!!! -- variable number of arguments and return values and the ease of use. Didn't bother to search if the python has this too... :) -- is very fast!
So, thank you for Lua!!!!
P.S. I'll wait to pull the server in a semi usable state. After that, I think I will make it publicly available... Or parts of it... |
