 |
lua-l archive |
|
|
||
|
Lanes locks around calls to 'require' so that only one can be done at a time. This is essentially all support a multithreading library can give to a module, I think.
Using a leaking module would anyways be on the responsibility of the module author and/or user, but if there's something Lanes could do about this, please suggest. We can recycle states but I wouldn't start relying on such behaviour. In fact, I think Lanes suits and was designed for other kind of applications than daemons. They often have a limited scope of what they're doing (compared to, say, a GUI application) and would do better with a cache table of preset states. Lanes is for usage where one would not like to touch anything on the C side.
-asko gary ng kirjoitti 11.11.2007 kello 9:11:
... Another issue which I don't see people mentioning is how to properly clean up these lua states. My experience with 'rings' is that for certain third party modules(say the luasql.mysql binding), it is impossible to properly clean up a lua state(memory leaks). So both lua lane and luatask if used in the erlang manner(repetitively create and destroy states like function calls), would have issues for writing daemon process. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com