Re: clarifying/understanding luv event loop, threads

[Tim Caswell]

There is exactly one Lua state and libuv uv_loop_t per OS thread. 

Lua coroutines are called threads by Lua, but it's coorporative threading, purely a construct within that Lua state, and has nothing to do with system level preemptive threads.

Since libuv loops use non-blocking IO, you can have as many concurrent servers, file readers, repls, etc as you want, a sharing the same Lua state and same OS thread.

The thread module in luv exposes some os thread related functions in libuv and is rather advanced and experimental.  I've never used it personally and can't say what all it supports.

You may be able to mix in blocking libraries using the thread extension, but, again, it's advanced and I won't be able to help much.  The recommended path is to stick to non-blocking libraries and not mix concurrency models.

On May 21, 2017 11:12 PM, <srinath.kr...@gslab.com> wrote:

Hi,

Working off the blog at https://luvit.io/blog/pure-luv.html, and the examples/ under luv, I seem to have a working prototype of a CLI with embedded http server.

 For this, I've used the repl example from luv, coupled with the web-server example at the blog above.

(I have very basic understanding of node-js event loop.)

Have few very basic conceptual questions - please do point me to any relevant docs that I've missed out on (I read libuv docs which give some clarity, but I'm not sure of interpretation within lua) : 

1. By doing prototype, I now have two event loops (repl, http) running - is that correct? Or is there a single event-loop getting events from two sources?

How's the (global lua) state shared across the underlying threads)? Do the two event loops (or threads) automatically synchronize access to global (lua) variables, or are there any other points I need to take care of? (Some more clarity on internal workings would be great...)

2. I would ideally want to use some other libraries in their own thread without affecting main event loop (e.g. suppose we wish to use some other CLI like linenoise); for this, I should be able to create a new thread and if I invoke the CLI from that thread all of this should not affect the event loop, but the global state needs to be shared (with again any synchronization caveats?)... unfortunately I'm unable to get the thread-library working right off (see comments in blog for issue faced) - any thoughts/suggestions on this?

Thanks,

Srinath.

--
You received this message because you are subscribed to the Google Groups "luvit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to luvit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.