00:15:05  * vtjnash_joined
00:15:18  <vtjnash_>jshanab_: "when there are active idle handles, the loop will perform a zero timeout poll instead of blocking for i/o."
00:15:40  <vtjnash_>If you're referring to http://docs.libuv.org/en/v1.x/guide/utilities.html#idler-pattern, I don't think the example in the docs is correct
00:15:51  <vtjnash_>That's just not a particularly good way to implement a progress notification system
00:15:56  <vtjnash_>The example from libev (of which libuv was originally a wrapper) is more meaningful (http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#WATCHER_PRIORITY_MODELS)
00:16:33  <jshanab_>Good, I thought it was incorrect. I just want to make sure I am understanding correctly.
00:18:07  <jshanab_>I have a program with a series of plugins nad in each plugin runs a loop that pulls messages from a queue then calls Set on all it's children to collect sockets, calls select(), then calls isset() to execute functions in each child.
00:18:42  <vtjnash_>Are you aware of uv_backend_fd?
00:19:01  <jshanab_>I am thinking an uv_asyc_t will be how the main program tells the loop that it neesd to pull an item from the queue.
00:19:35  <jshanab_>I am learning. I think I will need a combination of socket, asysnc and other handles.
00:19:47  <vtjnash_>Depends on your application constraints
00:20:12  <vtjnash_>If you can move libuv to a separate thread, that's a good option, and then uv_async_t is useful
00:20:43  <jshanab_>This is a large well established application that, I think needs help scaling. The goal here is to test that theory!
00:21:11  <vtjnash_>If you can let libuv control the primary event loop, then uv_idle_t can be a good way to schedule callbacks to finish later
00:22:01  <vtjnash_>libuv lets you embed in either direction (providing both uv_poll_t and uv_backend_fd) that the underlying OS supports
00:23:20  <jshanab_>I am thinking of multiple loops with some signaling for coordination. The reason here is to separate high freq small packet data from low freq large packet data, XML vs rtp. And to test if divideing into multiple loops will allow things to utilize more cores.
00:24:42  <jshanab_>I have another question. Is there any priority to the handles? I mean is there a way to say this group of handles should run first if evented?
00:28:23  <vtjnash_>multiple libuv loops can be very annoying to work with, since it costs higher overhead (is slower) and you have to keep them straight
00:28:42  <vtjnash_>*separate the handles
00:29:14  <vtjnash_>no, it seems libuv never needed priority, so it just implemented round-robin
00:30:06  <vtjnash_>in theory, multiple loops could crank the CPU harder if you are running them on different threads
00:41:30  * vtjnashjoined
01:00:39  * vtjnashquit (Remote host closed the connection)
01:07:19  <jshanab_>"crank the CPU harder" ??? The idea here is to bring in another core or 2 or 4. Everything I see says threads are the first part of that. The caveote is that they be well isolated. These would be stream workers, so well isolated.
01:09:14  <jshanab_>Trade some small added overhead for the ability to use more cores
01:16:23  <vtjnash_>they need to run completely independent uv_loops
01:16:51  <vtjnash_>It's often simpler to run multiple processes
01:32:58  * vtjnashjoined
01:34:49  * vtjnashquit (Remote host closed the connection)
02:02:11  * vtjnashjoined
02:24:14  * vtjnashquit (Remote host closed the connection)
02:24:43  * vtjnashjoined