00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:03  * c4miloquit (Remote host closed the connection)
00:00:14  * ircretaryjoined
00:09:36  * stagasquit (Ping timeout: 272 seconds)
00:19:25  * andrehjrquit (Quit: ["Textual IRC Client: www.textualapp.com"])
00:19:55  * piscisaureusquit (Ping timeout: 255 seconds)
00:33:39  * chris_99quit (Quit: Ex-Chat)
00:34:06  * AlexisMochajoined
00:44:38  * iarnajoined
00:49:10  * iarnaquit (Ping timeout: 255 seconds)
01:20:59  * iarnajoined
01:26:20  * a_lejoined
01:26:51  * brsonjoined
01:39:55  * iarnaquit (Remote host closed the connection)
01:41:46  * mihaikioquit (Remote host closed the connection)
01:42:29  * mihaikiojoined
01:49:06  * c4milojoined
01:53:37  * c4miloquit (Ping timeout: 245 seconds)
01:58:56  * mihaikioquit (Remote host closed the connection)
01:59:08  * mihaikiojoined
02:00:08  * jgiquit (Quit: jgi)
02:16:01  * brsonquit (Quit: leaving)
02:26:01  <M28>does libuv work well with fork?
02:32:27  * c4milojoined
02:40:20  * iarnajoined
02:40:27  * AlexisMochaquit (Ping timeout: 258 seconds)
02:47:44  * iarnaquit (Ping timeout: 245 seconds)
03:04:42  <mmalecki>M28: if you want to fork() to spawn a child process, there's an API for that in libuv. if you want to just fork(), that didn't work well last time I tried
03:05:03  <M28>okay
03:05:06  <mmalecki>M28: that was due to the thread pool not being spun up by the child correctly
03:13:47  * qard_joined
03:15:23  * qard_quit (Client Quit)
03:29:58  * petka_quit (Quit: Connection closed for inactivity)
03:36:34  * a_lequit (Remote host closed the connection)
03:39:08  * chris_99joined
03:47:01  * c4miloquit (Remote host closed the connection)
03:49:03  * mihaikioquit (Remote host closed the connection)
03:49:36  * mihaikiojoined
04:01:25  * kvanbjoined
04:04:15  <kvanb>indutny: did you mean something like buffer = uv_buf_init("test", 4); ?
04:24:56  * Left_Turnquit (Quit: Leaving)
04:37:44  * avalanche123joined
04:41:56  <kvanb>indutny: nevermind, it worked. thanks!!
04:42:25  * avalanche123quit (Ping timeout: 265 seconds)
04:42:33  * toothrotquit (Ping timeout: 260 seconds)
04:55:22  * Fishrock123quit (Quit: Leaving...)
04:59:39  * iarnajoined
05:03:57  * iarnaquit (Ping timeout: 255 seconds)
05:09:07  * jgijoined
05:15:38  * qardquit (Remote host closed the connection)
05:16:12  * iarnajoined
05:18:12  * mihaikioquit (Read error: Connection reset by peer)
05:18:49  * mihaikiojoined
05:27:15  * dshaw_joined
05:35:31  * dshaw_quit (Read error: Connection reset by peer)
05:35:38  * dshaw_joined
05:35:56  * c4milojoined
05:40:46  * c4miloquit (Ping timeout: 255 seconds)
05:41:29  * AvianFluquit (Ping timeout: 245 seconds)
05:49:30  * chris_99quit (Remote host closed the connection)
06:00:53  * dshaw_quit (Ping timeout: 256 seconds)
06:33:51  * iarnaquit (Remote host closed the connection)
06:45:03  * iarnajoined
06:54:29  * rmgjoined
06:59:17  * rmgquit (Ping timeout: 260 seconds)
07:02:19  * jgiquit (Quit: jgi)
07:17:15  * stagasjoined
07:24:45  * c4milojoined
07:29:37  * c4miloquit (Ping timeout: 260 seconds)
07:34:51  * stagasquit (Quit: Bye)
07:46:39  * Ldxngxjoined
07:46:43  * Ldxngxquit (Client Quit)
07:46:52  * Ldxngxjoined
07:47:29  * Ldxngxquit (Client Quit)
07:47:38  * Ldxngxjoined
08:03:29  * ijrothjoined
08:06:04  * janjongboomjoined
08:10:52  * kvanbquit (Ping timeout: 256 seconds)
08:21:19  * rendarjoined
08:23:17  * thlorenzjoined
08:45:05  * mihaikioquit (Remote host closed the connection)
08:45:21  * mihaikiojoined
08:51:48  * a_lejoined
09:12:59  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:13:54  * c4milojoined
09:15:50  * avalanche123joined
09:17:31  * iarnaquit (Remote host closed the connection)
09:17:57  * thlorenzquit (Remote host closed the connection)
09:18:49  * c4miloquit (Ping timeout: 260 seconds)
09:20:17  * avalanche123quit (Ping timeout: 245 seconds)
09:27:14  * mihaikioquit (Remote host closed the connection)
09:27:47  * mihaikiojoined
09:30:45  * janjongboomjoined
09:36:25  * a_lequit (Remote host closed the connection)
09:43:37  * iarnajoined
09:47:28  * janjongboomquit (Ping timeout: 265 seconds)
09:48:50  * janjongboomjoined
10:18:11  * janjongboomquit (Ping timeout: 244 seconds)
10:19:38  * janjongboomjoined
10:20:13  * thlorenzjoined
10:29:07  * piscisaureusjoined
10:31:38  * Left_Turnjoined
10:33:59  * seishunjoined
10:49:07  * bajtosjoined
10:53:50  * bajtosquit (Ping timeout: 244 seconds)
10:53:53  * inolenquit (Quit: Leaving.)
11:02:34  * c4milojoined
11:02:34  * janjongboomquit (Ping timeout: 256 seconds)
11:03:52  * janjongboomjoined
11:07:28  * c4miloquit (Ping timeout: 255 seconds)
11:08:03  * AlexisMochajoined
11:18:22  * janjongboomquit (Ping timeout: 240 seconds)
11:19:38  * janjongboomjoined
11:21:12  * chris_99joined
11:27:52  * bajtosjoined
11:30:36  * iarnaquit (Remote host closed the connection)
11:33:44  * petka_joined
11:42:19  * iarnajoined
11:46:41  * kazuponjoined
11:48:48  * iarnaquit (Remote host closed the connection)
11:53:50  * kazuponquit
11:56:59  * kazuponjoined
12:02:38  * janjongboomquit (Ping timeout: 256 seconds)
12:02:44  * bajtosquit (Quit: bajtos)
12:03:44  * janjongboomjoined
12:10:27  * ijrothquit (Quit: Leaving.)
12:17:02  * iarnajoined
12:17:10  * kazuponquit (Remote host closed the connection)
12:18:51  * kazuponjoined
12:32:25  * kazuponquit (Remote host closed the connection)
12:36:37  * thlorenzquit (Remote host closed the connection)
12:43:19  * AvianFlujoined
12:43:52  * kazuponjoined
12:46:29  * thlorenzjoined
12:51:29  * c4milojoined
12:56:17  * c4miloquit (Ping timeout: 260 seconds)
12:56:58  * iarnaquit (Remote host closed the connection)
13:06:33  * AlexisMochaquit (Ping timeout: 260 seconds)
13:07:01  * AvianFluquit (Ping timeout: 256 seconds)
13:12:52  * lance|afkchanged nick to lanceball
13:24:52  * toothrotjoined
13:26:05  * iarnajoined
13:26:40  * AvianFlujoined
13:30:25  * thlorenzquit (Remote host closed the connection)
13:35:34  * kazuponquit (Remote host closed the connection)
13:41:21  * kazuponjoined
13:51:03  * kriskowalquit (Ping timeout: 244 seconds)
13:51:12  * Ldxngxquit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
13:51:52  * Ldxngxjoined
14:02:23  <LinuxJedi>I'm seeing an odd behaviour in 0.10 which could well be my bug but want to make sure it isn't. I'm calling uv_read_stop() on a TCP stream and then uv_run with UV_RUN_ONCE. It appears to block on polling the stream I just told it to stop reading. Is that expected behaviour?
14:08:57  * toothrotquit (Ping timeout: 265 seconds)
14:12:02  * AlexisMochajoined
14:14:54  * Fishrock123joined
14:16:02  * Fishrock123quit (Read error: Connection reset by peer)
14:16:08  * Fishrockjoined
14:17:16  * lanceballchanged nick to lance|afk
14:17:46  * iarnaquit (Read error: Connection reset by peer)
14:18:16  * iarnajoined
14:18:28  <LinuxJedi>crap, yes it is. uv_read_stop() only stops read events on a connection, it doesn't stop polling a connection *slaps forehead*
14:19:51  * kriskowaljoined
14:21:08  * iarnaquit (Read error: Connection reset by peer)
14:21:42  * iarnajoined
14:28:41  * iarnaquit (Read error: Connection reset by peer)
14:29:10  * iarnajoined
14:34:13  * iarnaquit (Read error: Connection reset by peer)
14:37:23  * bajtosjoined
14:39:20  * iarnajoined
14:39:25  * avalanche123joined
14:40:40  * c4milojoined
14:40:56  * iarnaquit (Remote host closed the connection)
14:42:17  * iarnajoined
14:43:52  * avalanche123quit (Ping timeout: 240 seconds)
14:45:13  * iarnaquit (Remote host closed the connection)
14:45:30  * c4miloquit (Ping timeout: 272 seconds)
14:56:05  * lance|afkchanged nick to lanceball
15:01:33  <janjongboom>piscisaureus: you in NL?
15:12:38  <nathan7>hey humans
15:16:31  <janjongboom>no humans here
15:16:33  <janjongboom>move along sir
15:16:35  * inolenjoined
15:16:35  <janjongboom>nothing to see
15:16:47  * robertkowalskijoined
15:18:34  * kriskowalquit (Ping timeout: 245 seconds)
15:23:23  * inolenquit (Quit: Leaving.)
15:27:22  * kazuponquit (Remote host closed the connection)
15:28:48  * kazuponjoined
15:32:46  * iarnajoined
15:35:02  * iarnaquit (Remote host closed the connection)
15:35:31  * iarnajoined
15:37:53  * chris_99quit (Ping timeout: 240 seconds)
15:39:44  * kriskowaljoined
15:39:52  * iarnaquit (Ping timeout: 250 seconds)
15:42:23  * chris_99joined
15:42:37  * bradleymeckjoined
15:55:44  * kazuponquit (Remote host closed the connection)
15:59:39  * a_lejoined
16:08:16  * chris_99quit (Ping timeout: 265 seconds)
16:08:31  * mitsuhikoquit (Ping timeout: 258 seconds)
16:09:13  * mitsuhikojoined
16:09:13  * mitsuhikoquit (Changing host)
16:09:13  * mitsuhikojoined
16:10:37  * chris_99joined
16:11:45  * bajtosquit (Quit: bajtos)
16:14:48  * mihaikioquit (Ping timeout: 272 seconds)
16:23:55  * iarnajoined
16:25:41  * iarnaquit (Remote host closed the connection)
16:29:21  * c4milojoined
16:30:42  * octetcloudjoined
16:31:05  * iarnajoined
16:31:28  * brsonjoined
16:32:50  * iarnaquit (Remote host closed the connection)
16:34:04  * c4miloquit (Ping timeout: 256 seconds)
16:41:49  * avalanche123joined
16:43:34  * mihaikiojoined
16:56:28  * kazuponjoined
16:59:57  * avalanche123quit (Remote host closed the connection)
17:00:43  * bajtosjoined
17:01:16  * kazuponquit (Ping timeout: 256 seconds)
17:04:44  * jgijoined
17:07:10  * rmgjoined
17:07:21  * dap_joined
17:14:04  <Wraithan>I'm seeing gradual over time memory growth (RSS, but not Heap) on processes that use TLS. I know others have spoken about this. Anyone happen to have a link to the issue if there is one?
17:18:31  <tjfontaine>for v0.10 or v0.11?
17:18:44  <tjfontaine>there's more anecdotal evidence so far
17:18:57  <tjfontaine>there have been a couple tickets in the past where discrete issues were solved
17:21:50  <Wraithan>v0.10
17:24:10  <tjfontaine>Wraithan: do you have a core file that we can do a ::findjsobects on and see what types of objects are sticking around?
17:24:17  <Wraithan>It isn't a significant amount of memory
17:24:54  <tjfontaine>whats' the growth rate then?
17:25:15  <Wraithan>I was just figuring that out (the exact, I working backwards from graphs)
17:25:18  <tjfontaine>what is observing the memory usage, process.memoryUsage() or external tools?
17:26:00  <tjfontaine>I'm mostly interested to know if the V8 object tracking shows growth that matches the rate of RSS you may be seeing grow externally
17:26:22  <Wraithan>process.memoryUsage() it is about 10mb over about 60 hours
17:26:47  <tjfontaine>but in the V8 object usage or merely in its rss accounting?
17:26:54  <Wraithan>Tracking heap, rss, and heaptotal. Heap is staying pretty constant (both the total and the used)
17:27:05  <Wraithan>Only rss is increasing
17:27:17  <tjfontaine>ok so there are two cases for this to happen
17:27:34  <tjfontaine>1) we have a traditional heap leak (quite probable)
17:27:46  <tjfontaine>2) gc compaction is not firing very often
17:27:57  <Wraithan>Yeah, I don't see any compaction across the processes
17:28:16  <Wraithan>at least not any of significance
17:28:36  <tjfontaine>doing regular pmap's of the process will let you know if it's the mmap'd regions (V8 space) or native heap where you're seeing growth
17:29:32  <Wraithan>tjfontaine: I'll see about adding regular pmaps to my data collection
17:29:46  <Wraithan>I'll run it for a couple days to see if the compaction happens
17:29:57  <tjfontaine>nod
17:30:26  <tjfontaine>there are tools that can be used to nail down the native heap leak (if that's where it is)
17:30:29  * avalanch_joined
17:30:50  <Wraithan>I'm in the middle of other features, so this memory profiling is a spare time thing for now.
17:31:05  <Wraithan>But I'll add more stuff on Thursday/Friday and check back in
17:39:21  * a_lequit (Remote host closed the connection)
17:49:05  * iarnajoined
17:50:50  * iarnaquit (Remote host closed the connection)
17:51:13  * janjongboomquit (Ping timeout: 265 seconds)
17:51:53  * janjongboomjoined
17:54:24  * bradleymeckquit (Quit: bradleymeck)
17:57:27  * kazuponjoined
17:57:39  <chrisdickinson>tjfontaine: would running with --always_compact show whether the growth was down to compaction?
17:58:06  <tjfontaine>chrisdickinson: if pmap shows the growth is in mmap'd regions I would expect always_compact to remedy the issue
17:59:09  <Wraithan>Maybe I'll do both. Add pmap monitoring to the processes and spin up another cluster that runs with --always_compact
17:59:53  <tjfontaine>I advocate minimal changes
18:00:11  <tjfontaine>but 10mb over 60 hours seems like an easily reproduced rate
18:00:41  <Wraithan>tjfontaine: I can spin up a few more clusters before IT gets mad at me for using tons of their processors
18:00:56  <Wraithan>so I can try permutations
18:01:08  <tjfontaine>how minimal is the test case?
18:01:29  <tjfontaine>I'd love to turn on UMEM_DEBUG and let it run
18:02:27  * kazuponquit (Ping timeout: 255 seconds)
18:03:14  <Wraithan>tjfontaine: has the newrelic agent and express. I can gist the files.
18:03:38  * inolenjoined
18:03:57  <tjfontaine>Wraithan: nothing else special? then I'd love to just let it run as well
18:04:19  <tjfontaine>if it's native heap leaking we can catch that in the act pretty easy with ::findleaks
18:05:55  <Wraithan>tjfontaine: I'll gist it. You'll need a newrelic license. you happen to have one already? If not let me know and we can give you something for testing
18:08:08  <tjfontaine>Wraithan: I don't think I have any personal ones, Joyent probably has some partner things, groundwater_ was supposed to hook me up a while back
18:08:37  <Wraithan>tjfontaine: mind a PM?
18:09:30  <tjfontaine>Wraithan: go for it
18:10:15  * iarnajoined
18:12:00  * iarnaquit (Remote host closed the connection)
18:14:34  * lanceballchanged nick to lance|afk
18:14:37  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:15:34  * janjongboomjoined
18:18:14  * c4milojoined
18:19:43  * janjongboomquit (Ping timeout: 244 seconds)
18:20:01  <Wraithan>tjfontaine, chrisdickinson: here is my test server: https://gist.github.com/wraithan/60a72ffa4fbe68da06b0
18:20:36  * iarnajoined
18:20:37  <tjfontaine>Wraithan: how often are you pinging it with a client?
18:21:45  <Wraithan>tjfontaine: I hit /stats every 10s. I have one cluster that is taking about 1k/s to /. And I have another that is doing about 10-100s to /. Both exhibit the problem.
18:21:53  <Wraithan>10-100/s that is
18:21:55  * ijrothjoined
18:22:14  <tjfontaine>any thing indicating it makes it faster/slower?
18:23:04  <Wraithan>Nope, constant regardless, which is what made me think it was something in the harvest cycle that runs once per minute regardless of hits per second. And easy thing to test was disabling SSL
18:23:04  * c4miloquit (Ping timeout: 258 seconds)
18:23:19  <Wraithan>tjfontaine: and this is constant regardless of hapi or express
18:23:29  * a_lejoined
18:23:37  <tjfontaine>nod
18:24:24  <tjfontaine>so it could/should actually leak without anything communicating with the server, and only the tls client reporting home?
18:25:30  <Wraithan>tjfontaine: possibly
18:25:39  <Wraithan>I haven't whittled down the case to be even less
18:25:49  <tjfontaine>Wraithan: can we up the rate at which the agent reports?
18:26:42  <Wraithan>tjfontaine: I wonder if that will take when you set it in the config. I always just modify it directly on the resulting config. Let me test and see
18:27:38  * a_lequit (Remote host closed the connection)
18:27:44  * dshaw_joined
18:28:16  * a_lejoined
18:32:28  <Wraithan>tjfontaine: looks like you can't, the server will send down a value to override you if you try to change it from newrelic.js. We do this to make sure people don't turn up the agent to hammer our servers harder
18:32:56  <tjfontaine>Wraithan: how much would we need to do to mock up a fake server?
18:33:09  <tjfontaine>I don't want to change too much obviously
18:33:31  <tjfontaine>I'll just start with what we have, but ideally we should be able to replace with a socat server
18:34:34  <Wraithan>tjfontaine: we have a collector that we call evil-collector (think chaos monkey + api endpoints) that groundwater_ built, but afaik we can't release that one
18:35:02  <tjfontaine>ok
18:35:10  <tjfontaine>we'll just do the happy case
18:35:41  * seishunquit (Remote host closed the connection)
18:38:06  * seishunjoined
18:38:06  * inolenquit (Ping timeout: 265 seconds)
18:39:03  * inolenjoined
18:40:57  * stagasjoined
18:41:11  * octetcloudquit (Quit: WeeChat 1.0.1)
18:42:11  * ijrothquit (Quit: Leaving.)
18:45:05  * dshaw_quit (Quit: Leaving.)
18:45:15  * qardjoined
18:46:06  * avalanch_quit (Remote host closed the connection)
18:52:39  <tjfontaine>Wraithan: what's the default reporting period then?
18:52:53  <Wraithan>tjfontaine: 60s
18:53:14  <tjfontaine>Wraithan: ok
18:53:28  <tjfontaine>I'm capturing dumps and memory layouts every 10mins
18:53:32  <Wraithan>cool
18:53:45  <tjfontaine>I'll come back in a couple hours and see where we are
18:54:04  <tjfontaine>I also have a `while true; do curl -sS http://localhost:5000/stats > /dev/null; done`
18:54:07  <Wraithan>tjfontaine: sounds great, I have a meeting then lunch so I was about to say I can help until after that
18:54:09  <creationix>in the event loop, which generally happens first after use code? uv_check or uv_prepare?
18:54:24  <creationix>and do timers happen at the same time as I/O?
18:54:28  <Wraithan>Er, I can't help until after that
18:54:32  <tjfontaine>Wraithan: nod
18:54:40  <tjfontaine>creationix: why?
18:54:54  <tjfontaine>creationix: the answer is in src/<platform>/core.c
18:55:02  <tjfontaine>or something similarly named I think
18:55:08  <creationix>tjfontaine: I’m trying to implement nextTick-like semantics in luvit without needing an event source hook
18:55:17  * qard-appnetapart
18:55:30  <tjfontaine>in uv_run
18:55:53  <tjfontaine>creationix: well, nextTick semantics are actually disconnected from anything to do with the eventloop
18:56:09  <tjfontaine>more or less
18:56:12  <creationix>right, looks like I can’t use prepare or check to emulate them
18:56:33  <tjfontaine>well, you can, for something much more akin to what the name of the feature suggests
18:56:47  <tjfontaine>either a check or prepare being active while there are things enqueued makes sense
18:56:49  <creationix>do you know how setImmediate works in node?
18:56:56  <tjfontaine>yes I do, I wrote it :)
18:57:14  <piscisaureus>creationix: prepare happens right before epoll()/kqueue(). Check happens after that.
18:57:24  <piscisaureus>after kqueue/epoll that is
18:58:01  <tjfontaine>setImmediate behaves like what you're suggesting you want
18:58:16  <tjfontaine>nextTick in Node.js is nothing like that
18:58:21  <tjfontaine>at least in v0.10 and beyond
18:58:24  <piscisaureus>creationix: but in general I would suggest to use an uv_idle to call a nextTick. And what TJ said about nextTick being very different.
18:58:47  <creationix>but I like how nextTick works in node, it just needs a new name
18:58:56  <creationix>end-of-tick or something
18:59:02  <tjfontaine>that's not what it is though
18:59:24  <tjfontaine>it's "clear-list-while-async-transition-happens"
18:59:33  <piscisaureus>well it has some form of recursive queuing. The callback is inserted at a very specific point. That's what makes it different.
19:00:06  <creationix>right, I implemented several early versions of next tick. The recursive queue that can block the loop if your not careful is a feature to me
19:00:12  * avalanche123joined
19:00:21  <creationix>anyway, looking at core.c, I see that none of the uv hooks can be used for that
19:00:21  <tjfontaine>it's not exactly recursive, the list will be iterated in a traditional way
19:00:32  <piscisaureus>with libuv you can't queue recursively
19:00:54  <tjfontaine>you can't push yourself into the timer list to always block?
19:00:57  * c4milojoined
19:01:01  <creationix>piscisaureus: right, so if I create a uv_check inside the callback to another uv_check, it won’t get called till next time through right?
19:01:03  <tjfontaine>it's an RB tree right?
19:01:20  <piscisaureus>creationix: hmm... I think so. This may be untested :)
19:01:49  <creationix>tjfontaine: so does setImmediate use check or prepare/idle?the nex
19:01:52  <piscisaureus>the timer manager is either an rb-tree or a heap.
19:02:01  <piscisaureus>you can't push yourself into it
19:02:25  <piscisaureus>but timers are only invoked once per loop iteration
19:02:53  <tjfontaine>creationix: it's a check iirc
19:03:01  <piscisaureus>nextTick callbacks gets called right after the callback that called nextTick
19:03:16  <tjfontaine>creationix: it's a check and an idle
19:03:33  <creationix>so is Idle preferred to prepare?
19:04:15  <tjfontaine>piscisaureus: btw re your nextTick ordering issue, I'm very wary of having a contract that describes the order across (at least perceived) event loop turns
19:04:27  <creationix>I guess with prepare, you might end up waiting a long-time if there is something active and slow in the loop
19:04:40  <piscisaureus>tjfontaine: you mean the issue I opened
19:04:52  <tjfontaine>piscisaureus: I think the state machine is already pretty hard, so just saying "in the future" in so far as not on the same turn is the best we can do -- the c-ares sometimes-sync issue is a bug
19:04:56  <tjfontaine>piscisaureus: ya
19:04:57  <piscisaureus>creationix: prepare and check technically are intending for doing last-minute things before blocking
19:05:07  <piscisaureus>tjfontaine: the problem is that nextTick happens *before* the tick ends
19:05:09  * mihaikioquit (Remote host closed the connection)
19:05:19  <tjfontaine>piscisaureus: but after your code that enqueued it has executed
19:05:38  <piscisaureus>tjfontaine: nope. it should start with 1 and 2
19:05:44  <piscisaureus>tjfontaine: or does it not reproduce for you?
19:06:07  <creationix>nextTick can be implemented pretty easily with an event source hook (something that’s called right before and after user code for arbitrary events)
19:06:19  <tjfontaine>I mean the c-ares thing is a bug, but I think we should avoid a test that indicates that 3 should fire before 4
19:06:34  <piscisaureus>Oh, that way. I agree
19:06:42  <piscisaureus>tjfontaine: so 1 2 4 3 would also be acceptable
19:06:47  <tjfontaine>right
19:07:00  <creationix>ok, so in the event loop, I/O is the only thing that will ever block for a while right?
19:07:07  <piscisaureus>tjfontaine: I just wanted to show that it doesn't just break makeAsync, it also screws up the nextTick queue
19:07:29  <piscisaureus>creationix: ?
19:07:49  <tjfontaine>you mean uv__io_poll should be the only thing that libuv waits on in general?
19:08:00  * mihaikiojoined
19:08:29  <creationix>tjfontaine: right
19:08:45  <creationix>and it somehow knows to unblock if there is a timer ready?
19:08:51  * mihaikioquit (Remote host closed the connection)
19:08:56  <piscisaureus>creationix: yep
19:08:57  <tjfontaine>it sets an os level timer
19:09:01  <piscisaureus>nope
19:09:06  <tjfontaine>we don't use any os timers?
19:09:19  <piscisaureus>it computes the first upcoming timer
19:09:27  <piscisaureus>and then it passes that as the timeout to epoll/kqueue
19:09:38  <tjfontaine>ah that's a way to do that
19:09:46  <piscisaureus>it's also just faster
19:09:49  <creationix>and then UV_RUN_NOWAIT simply never blocks anywhere
19:09:51  <tjfontaine>I thought we also had os level timers
19:10:18  <piscisaureus>creationix: if you have idle watchers, or if you use nowait, the blocking timeout is set to 0
19:10:37  <creationix>so idle watchers run in a tight loop then?
19:10:57  <piscisaureus>creationix: they're called only once per loop iteration
19:11:29  <piscisaureus>but yes as long as there are active (started) idle handles the loop will busy-loop essentially
19:12:19  <creationix>ok, I think I’ll check in prepare and check to run my setImmediate callbacks then
19:12:27  * iarnaquit (Remote host closed the connection)
19:12:32  <piscisaureus>creationix: that may not be what you want
19:12:34  * mihaikiojoined
19:12:46  <creationix>hmm, no, that won’t work if I call setImmediate right before blocking on slow I/O
19:12:47  <piscisaureus>because what if you schedule a setImmediate
19:12:55  * iarnajoined
19:13:10  * iarnaquit (Remote host closed the connection)
19:13:13  <piscisaureus>creationix: well mostly what if you call it just before node calls epoll()
19:13:20  * iarnajoined
19:13:20  <creationix>right
19:13:27  * c4miloquit (Remote host closed the connection)
19:13:37  <creationix>so I guess I need to also do that at the stack level in the generic event handler code
19:14:21  <creationix>“nextTick” will run in a loop till none are left and setImmediate will only run callbacks that existed when the tick ended
19:14:30  <creationix>is that more or less how node does it?
19:14:58  <piscisaureus>nextTick will run immediately after the current callback
19:15:15  <piscisaureus>But if the callback schedules two or more nextTicks they are ran in order
19:15:23  <piscisaureus>I don't know about setImmediate. tjfontaine knows.
19:15:30  * dshaw_joined
19:16:52  <tjfontaine>there's a difference between setImmediate in v0.12 and v0.10
19:17:28  <tjfontaine>in v0.10 we [unfortunately] process one callback per turn, in v0.12 we process the whole list, but splice the list first, so any newly enqueued callbacks will fire on the next turn
19:18:03  <creationix>tjfontaine: ok, and that “per turn” is after every callback like nextTick?
19:18:20  <tjfontaine>no, this is the more literal sense of the event loop
19:18:24  <piscisaureus>tjfontaine: actually, rethinking it, 1 2 3 4 would be the only appropriate output
19:18:30  * mihaikioquit (Remote host closed the connection)
19:18:40  * seishunquit (Remote host closed the connection)
19:18:42  <tjfontaine>piscisaureus: because it *should* be enqueued before the cb fires, int his particular case yes
19:18:43  <creationix>ok, so I could do it with an idle check and kill the idle once the setImmediate queue is empty
19:18:44  <piscisaureus>tjfontaine: because nextTick is guaranteed to always have precendence
19:19:03  <tjfontaine>creationix: that's how it works for us, yes
19:19:13  <piscisaureus>That's how it's supposed to be done :)
19:19:13  * mihaikiojoined
19:19:17  <creationix>piscisaureus: what would be a better name for nextTick. I have a little more flexibility in luvit than node has
19:19:23  <piscisaureus>I guess
19:19:31  <piscisaureus>setImmediate :p
19:19:45  <creationix>lol, fair enough
19:19:46  <tjfontaine>creationix: https://github.com/joyent/node/blob/v0.10/src/node.cc#L2226-L2245
19:19:49  * seishunjoined
19:20:08  <piscisaureus>creationix: I'm also listening to a meeting. This is not a great time for me for trying to be creative
19:20:10  <creationix>tjfontaine: ok, so you put is in idle and check
19:20:18  <creationix>piscisaureus: no problem
19:20:32  <tjfontaine>creationix: https://github.com/joyent/node/blob/v0.10/lib/timers.js#L367-L370
19:20:44  <piscisaureus>creationix: what are you working on? I though Ryan Philips had taken over?
19:21:00  <creationix>piscisaureus: I work for rackspace now. Luvit is my day job
19:21:08  <creationix>we’re working on luvit 2.0
19:21:16  <piscisaureus>Oh haha cool
19:21:37  <piscisaureus>are they still using it for virgo?
19:21:40  <creationix>yep
19:22:10  <creationix>my new side project is dukluv.io (duktape + libuv). So I work with libuv day and night now
19:22:41  <piscisaureus>creationix: the idea is to start breaking things a bit after 1.0 gets released
19:22:54  <creationix>that will be fun. Let me know when you get there. I have lots of ideas
19:23:19  * rmgquit (Remote host closed the connection)
19:23:24  <piscisaureus>creationix: there are some design decisions that we consider not-great. Like only having requests (handle's shouldn't make callbacks)
19:23:39  <piscisaureus>and using a queue and not make callbacks directly
19:23:45  <creationix>I love both those ideas
19:23:49  <creationix>would simplify so much
19:23:50  <piscisaureus>and maybe (my faviorite) thread safety
19:24:07  <creationix>and allow my other pet idea of a non-callback interface where the user pulls from libuv one event at a time
19:24:18  <qard>I'm looking forward to 1.0. :D
19:24:22  <piscisaureus>yeah that's basically packet-based
19:24:33  <piscisaureus>when saul gets back I guess
19:24:43  <piscisaureus>There haven't been any serious issues reported since rc2 afaik
19:24:45  <creationix>luajit ffi would be blazing fast with a pull-style interface I think
19:24:58  * bajtosquit (Quit: bajtos)
19:25:08  <creationix>I filed an API tweak request around uv_fs_read, but nothing critical
19:25:39  * a_lequit (Remote host closed the connection)
19:25:41  <piscisaureus>There are some pracitical problems with packet-based though. We can discuss it when we get there.
19:25:50  <creationix>right
19:25:54  <piscisaureus>libuv would probably need to use callback-based dispatch internally anyway
19:26:16  * a_lejoined
19:26:31  <piscisaureus>because somehow "drivers" need to register actions like "when the write completes, call me back so I can schedule the next write in the queue"
19:26:57  <piscisaureus>which more or less makes callbacks a necessity (unless you want to build a giant switch statement somewhere)
19:27:57  <creationix>perhaps I’m not understand the queue idea then. We can talk about it later
19:28:38  * a_lequit (Remote host closed the connection)
19:33:26  * rendarquit (Ping timeout: 250 seconds)
19:39:02  * dshaw_quit (Quit: Leaving.)
19:39:05  <tjfontaine>Wraithan: in 40m I've not seen any native heap growth, only in the mmap'd v8 regions
19:40:05  * rendarjoined
19:40:14  * Ldxngxquit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
19:41:00  * piscisaureuspart
19:41:04  * piscisaureusjoined
19:41:13  * dshaw_joined
19:46:29  * kazuponjoined
19:51:21  * kazuponquit (Ping timeout: 255 seconds)
19:55:46  * lance|afkchanged nick to lanceball
19:55:59  * tarrudajoined
19:59:19  * Fishrockquit (Remote host closed the connection)
20:04:01  * a_lejoined
20:12:11  * janjongboomjoined
20:12:48  * inolenquit (Quit: Leaving.)
20:13:08  * inolenjoined
20:13:20  * a_lequit (Remote host closed the connection)
20:13:37  * avalanche123quit (Remote host closed the connection)
20:13:40  * inolenquit (Client Quit)
20:14:08  * avalanche123joined
20:15:00  * piscisaureusquit (Read error: Connection reset by peer)
20:15:32  * avalanche123quit (Remote host closed the connection)
20:15:44  * Fishrock123joined
20:15:48  * piscisaureusjoined
20:15:56  * piscisaureusquit (Client Quit)
20:18:12  * bradleymeckjoined
20:23:50  * rmgjoined
20:25:37  * inolenjoined
20:25:38  * inolenquit (Client Quit)
20:29:20  * rmgquit (Ping timeout: 265 seconds)
20:39:25  * avalanche123joined
20:40:50  * avalanche123quit (Remote host closed the connection)
20:42:10  * avalanche123joined
20:51:37  * mihaikioquit (Remote host closed the connection)
20:52:08  * mihaikiojoined
20:56:22  * rmgjoined
20:56:31  * mihaikioquit (Ping timeout: 255 seconds)
21:00:04  * janjongboomquit (Read error: Connection reset by peer)
21:00:09  * janjongb_joined
21:00:59  * lanceballchanged nick to lance|afk
21:02:21  * c4milojoined
21:03:25  * thlorenzjoined
21:05:15  * janjongb_quit (Read error: Connection reset by peer)
21:05:29  * janjongboomjoined
21:06:39  * jgiquit (Quit: jgi)
21:07:07  * c4miloquit (Ping timeout: 244 seconds)
21:07:56  * thlorenzquit (Ping timeout: 265 seconds)
21:10:11  * thlorenzjoined
21:14:46  * M28quit (Read error: Connection reset by peer)
21:15:05  * M28joined
21:28:36  * thlorenzquit (Remote host closed the connection)
21:32:07  * a_lejoined
21:33:28  * lance|afkchanged nick to lanceball
21:35:29  * kazuponjoined
21:39:15  * mihaikiojoined
21:41:42  * kazuponquit (Ping timeout: 250 seconds)
21:44:37  * thlorenzjoined
21:45:47  * c4milojoined
21:50:59  * thlorenzquit (Remote host closed the connection)
21:51:17  * thlorenzjoined
21:51:24  * a_lequit (Read error: Connection reset by peer)
21:51:59  * a_lejoined
21:55:30  * a_lequit (Remote host closed the connection)
21:56:12  * seldojoined
21:56:20  * iarnaquit (Remote host closed the connection)
21:56:33  * a_lejoined
21:56:57  * tarrudaquit (Ping timeout: 245 seconds)
21:57:24  * jgijoined
22:05:16  * iarnajoined
22:09:18  <chrisdickinson>tjfontaine: ever used ::v8print to display the contents of a ExternalUnsignedByteArray?
22:09:51  <tjfontaine>you want to inspect a node buffer I take it?
22:10:03  <tjfontaine>I can teach you how to do it today, but I have good news coming down the line from dap
22:11:22  <tjfontaine>chrisdickinson: https://gist.github.com/tjfontaine/754606eeb9b92943c074 (its +8 not +4 on 64bit installs)
22:11:43  <tjfontaine>https://github.com/davepacheco/node/commit/f46c29e390a0681e8272f687c52737997b512722 from dap
22:11:46  * a_le_joined
22:11:59  * a_lequit (Read error: Connection reset by peer)
22:12:31  <chrisdickinson>rad, thanks!
22:14:44  <tjfontaine>chrisdickinson: is that what you were looking to do?
22:15:25  * ijrothjoined
22:15:39  <chrisdickinson>yep, that's perfect!
22:19:21  * tarrudajoined
22:20:28  * seldo_joined
22:20:57  * Fishrock123quit (Remote host closed the connection)
22:21:07  * seldoquit (Read error: Connection reset by peer)
22:28:24  * tarrudaquit (Ping timeout: 255 seconds)
22:29:18  * lanceballchanged nick to lance|afk
22:30:39  * seishunquit (Ping timeout: 245 seconds)
22:31:01  * seldojoined
22:32:17  * bradleymeckquit (Quit: bradleymeck)
22:33:17  * seldo_quit (Ping timeout: 264 seconds)
22:36:24  * rendarquit
22:36:38  * seldo_joined
22:37:42  * Fishrock123joined
22:38:00  * kazuponjoined
22:39:12  * seldoquit (Ping timeout: 255 seconds)
22:42:42  * kazupon_joined
22:43:15  * kazuponquit (Ping timeout: 255 seconds)
22:46:16  * seldo_changed nick to seldo
22:47:08  * chris_99quit (Quit: Ex-Chat)
22:47:34  * kazupon_quit (Ping timeout: 265 seconds)
22:50:55  <jgi>trevnorris: ping
22:54:13  * ijrothquit (Quit: Leaving.)
22:54:45  * Guest24072joined
22:59:34  * c4miloquit (Remote host closed the connection)
23:07:16  * a_le_quit (Read error: Connection reset by peer)
23:07:30  * c4milojoined
23:08:34  * a_lejoined
23:14:43  * seldo_joined
23:17:20  * iarnaquit (Remote host closed the connection)
23:18:16  * seldoquit (Ping timeout: 255 seconds)
23:19:18  * seldo_changed nick to seldo
23:19:33  * ijrothjoined
23:24:51  * seldo_joined
23:28:10  * seldoquit (Ping timeout: 244 seconds)
23:31:28  * thlorenzquit (Remote host closed the connection)
23:40:37  * a_lequit
23:42:15  * a_lejoined
23:42:47  * Guest24072quit (Quit: WeeChat 0.4.2)