00:37:25  * mmaleckichanged nick to mrhotfix
00:37:44  * mrhotfixchanged nick to mmalecki
00:50:55  * c4miloquit (Remote host closed the connection)
00:56:50  * c4milojoined
00:58:26  * c4miloquit (Read error: No route to host)
01:03:01  * c4milojoined
01:11:55  * joshthecoderquit (Quit: Leaving...)
01:12:11  * dapquit (Quit: Leaving.)
01:14:36  * piscisaureusquit (Quit: Lost terminal)
01:21:24  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:23:00  * piscisaureus_joined
01:29:05  * ericktquit (Ping timeout: 268 seconds)
01:43:39  * abraxasjoined
01:44:07  * joshthecoderjoined
02:03:35  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:10:26  * ericktjoined
02:31:47  * brsonquit (Quit: leaving)
02:48:56  * c4miloquit (Remote host closed the connection)
02:50:09  * c4milojoined
02:51:49  * piscisaureus_quit (Ping timeout: 244 seconds)
03:05:17  * lohkey_joined
03:05:17  * lohkey_quit (Client Quit)
03:08:13  * lohkeyquit (Ping timeout: 276 seconds)
03:09:57  * TooTallNatejoined
03:23:57  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:27:15  * bnoordhuisquit (Ping timeout: 260 seconds)
03:30:05  * paddybyersjoined
03:33:32  * paddybyersquit (Client Quit)
03:58:32  * avalanche123joined
04:16:55  * mmaleckichanged nick to mmalecki[zzz]
04:35:04  * loladiroquit (Quit: loladiro)
05:51:45  * ericktquit (Quit: erickt)
05:52:02  * ibobrikjoined
06:04:58  * lohkeyjoined
06:06:20  * lohkeyquit (Client Quit)
06:07:00  * ibobrikquit (Read error: Connection reset by peer)
06:07:31  * avalanche123quit (Quit: Computer has gone to sleep.)
06:12:35  * toothrotquit (Ping timeout: 240 seconds)
06:32:34  * c4miloquit (Read error: Connection reset by peer)
06:33:15  * c4milojoined
06:50:39  * toothrjoined
06:51:07  * c4miloquit (Read error: Connection reset by peer)
07:00:06  * c4milojoined
07:20:48  * rendarjoined
08:01:54  * felixgejoined
08:01:54  * felixgequit (Client Quit)
08:26:53  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
09:22:49  * mmalecki[zzz]changed nick to mmalecki
10:48:14  * beachdogjoined
10:57:53  * beachdogquit (Remote host closed the connection)
11:04:47  * rendarquit
11:07:23  * abraxasquit (Read error: Connection reset by peer)
11:07:56  * abraxasjoined
11:13:56  * bnoordhuisjoined
11:16:13  * ArmyOfBrucequit (Excess Flood)
11:16:40  * ArmyOfBrucejoined
11:20:48  * FUUFREENODESTOPBjoined
11:21:10  * FUUFREENODESTOPBchanged nick to `3rdEden
11:23:30  * rendarjoined
11:29:36  * ibobrikjoined
11:55:31  <indutny>bnoordhuis: hey man
11:55:38  <bnoordhuis>indutny: ho man
11:56:19  <indutny>so about this streaming stuff
11:56:27  <bnoordhuis>what about it?
11:56:29  <indutny>bnoordhuis: do you think it would be better to do it in node
11:56:34  <indutny>or in libuv
11:56:43  <bnoordhuis>what streaming stuff are we talking about?
11:57:23  <indutny>excerpt
11:57:25  <indutny>01:32:13 <indutny> bnoordhuis: ok
11:57:25  <indutny>01:45:04 <indutny> bnoordhuis: I'm thinking about piping inside libuv
11:57:25  <indutny>01:45:34 <indutny> bnoordhuis: like creating a (sort of) socketpair from two streams and processing function
11:57:25  <indutny>01:46:01 <indutny> bnoordhuis: this looks like an API, not a conceptual change
11:57:25  <indutny>01:46:11 <indutny> though may have interesting impacts on how we deal with SSL in node
11:57:26  <indutny>01:46:47 <indutny> for example, we may have both cleartext and encrypted streams in uv and expose only sockets to node
11:57:26  <indutny>01:46:58 <indutny> which sounds really reasonable for me
11:57:27  <indutny>01:47:04 <indutny> bnoordhuis: what do you think?
11:57:54  <bnoordhuis>well... it all depends on what it actually is going to look like
11:59:23  <indutny>bnoordhuis: the thing preventing from being it libuv is that processing function should be called in a thread pool
11:59:57  <indutny>bnoordhuis: so it needs to be running it's own event loop
12:00:06  <indutny>well, sort of :)
12:00:32  <bnoordhuis>i don't think i'm really following
12:00:39  <bnoordhuis>can you sketch the api you have in mind?
12:00:57  <ibobrik>bnoordhuis: https://github.com/joyent/libuv/issues/544#issuecomment-8266084
12:02:20  <indutny>bnoordhuis: uv_pipe(stream_a, stream_b, pipe_cb, alloc_cb)
12:02:45  <indutny>void (*pipe_cb)(stream*, stream*, async_t* write_cb, uv_buf_t* buff);
12:02:54  <indutny>something like this
12:03:50  <bnoordhuis>indutny: where does the uv_buf_t come in?
12:03:59  <indutny>bnoordhuis: from read_cb
12:04:02  <bnoordhuis>ideally, you want to do zero copy operations where possible
12:04:07  <indutny>yes
12:04:12  <indutny>but it's impossible
12:04:17  <bnoordhuis>why?
12:04:26  <indutny>since processing function will feed incoming data to SSL
12:04:46  <bnoordhuis>so it's a special purpose api?
12:04:58  <indutny>sort of
12:05:14  <indutny>not sure if I follow it
12:05:16  <indutny>:)
12:05:20  <bnoordhuis>i don't quite see why it should be in libuv?
12:05:25  <indutny>me too
12:05:40  <indutny>ok, I need to think about it
12:05:44  <bnoordhuis>do that :)
12:05:59  <indutny>basically, I want to move all cleartext and encrypted streams piping into C++ land
12:06:03  <indutny>from tls.js
12:06:25  <bnoordhuis>what would you gain by that?
12:06:38  <indutny>speed?
12:06:52  <indutny>this stuff will be running on a thread pool
12:07:17  <indutny>making current implementation working via threads will require a lot of synchronization
12:07:39  <bnoordhuis>i wonder if you're going to see much of a speedup
12:07:44  <bnoordhuis>but i wouldn't mind being proven wrong
12:08:09  <indutny>bnoordhuis: I'm quite sure that I'll see better response times
12:08:26  <bnoordhuis>you're going to flesh out a proof of concept?
12:08:54  <indutny>probably
12:12:14  <indutny>I'll create addon for that :)
12:20:44  * paddybyersjoined
12:22:22  * mmaleckichanged nick to mmalecki[away]
12:22:42  * abraxasquit (Read error: Connection reset by peer)
12:23:40  * abraxasjoined
12:28:29  * abraxasquit (Ping timeout: 252 seconds)
13:30:24  * loladirojoined
13:35:53  * ericktjoined
13:46:57  * loladiroquit (Quit: loladiro)
13:52:04  * hzjoined
13:58:05  * piscisaureus_joined
14:00:32  * c4miloquit (Remote host closed the connection)
14:01:41  * c4milojoined
14:02:18  * loladirojoined
14:28:43  <piscisaureus_>indutny: I like piping inside libuv
14:28:51  <piscisaureus_>indutny: I also need this to catch up with httpsys :-)
14:28:59  * ibobrikquit (Quit: ibobrik)
14:33:38  * c4miloquit (Remote host closed the connection)
14:34:31  * c4milojoined
14:43:33  * TheJHjoined
14:54:38  * mmalecki[away]changed nick to mmalecki
15:01:18  <rphillips>has anyone seen an issue with libuv where an ECONNRESET causes a double close
15:01:42  <rphillips>it's probably a bug and race in luvit, but not sure where to look
15:10:32  <rphillips>are there any handles that are automatically closed?
15:12:41  <piscisaureus_>rphillips: no, that should never happen
15:12:58  <rphillips>ok. thanks
15:13:19  <piscisaureus_>rphillips: so it could be that if you have called read_start *and* have a pending write
15:13:24  <piscisaureus_>(or multiple pending writes)
15:13:41  <piscisaureus_>you will get the ECONNRESET multiple times
15:13:58  <piscisaureus_>so you have to be careful not to close the handle twice
15:16:08  * loladiroquit (Quit: loladiro)
15:17:55  <rphillips>ohhh
15:18:06  <rphillips>that is a great tip
15:18:57  <piscisaureus_>rphillips: so for now you can use uv_is_closing to see if a handle is already closing
15:24:18  * ibobrikjoined
15:31:11  <rphillips>piscisaureus_: i owe you a case of beer
15:31:18  <piscisaureus_>oh, another one :-)
15:31:47  <rphillips>:)
15:37:32  <piscisaureus_>bnoordhuis: yt?
15:39:04  <saghul>piscisaureus_ why did you say "for now"? is uv_is_closing going away?
15:39:14  <piscisaureus_>no
15:39:35  <piscisaureus_>maybe we can make it okay to uv_close a closing handle
15:39:40  <piscisaureus_>bnoordhuis might not agree
15:40:25  <bnoordhuis>piscisaureus_: ih
15:41:06  <piscisaureus_>bnoordhuis: can I get a signoff of the updated O3 pull request
15:41:27  <piscisaureus_>bnoordhuis: also, did you do anything this week that is worth mentioning
15:41:54  <bnoordhuis>piscisaureus_: as in, relevant to c9?
15:41:58  <piscisaureus_>yeah
15:42:06  <piscisaureus_>well, anything nontrivial
15:43:17  <bnoordhuis>piscisaureus_: no
15:43:42  <bnoordhuis>fixing bugs, the usual
15:48:29  <indutny>paddybyers: piping + processing
15:48:33  <indutny>oops
15:48:34  <indutny>piscisaureus_: ^^
15:48:57  <piscisaureus_>indutny: ?
15:49:04  <indutny>piscisaureus_: piping inside libuv
15:49:17  <piscisaureus_>indutny: yeah, that would be good
15:49:19  <indutny>piscisaureus_: what API method are you thinking about?
15:50:04  <piscisaureus_>indutny: later, ok. I'm having standup now
15:50:10  <indutny>sure
15:50:25  <piscisaureus_>indutny: actually, I have no ideas about api methods yet
15:50:31  <piscisaureus_>indutny: I just like the concept of it
15:51:37  <indutny>ok
15:51:44  <indutny>lets catch up later about it
15:51:48  <piscisaureus_>yea
15:52:00  <bnoordhuis>piscisaureus_: want me to join the standup?
15:52:09  <piscisaureus_>bnoordhuis: no
15:52:15  <bnoordhuis>oh :(
15:52:22  <piscisaureus_>bnoordhuis: I don't want you to not join the standup, either
15:52:33  * dapjoined
15:52:35  <bnoordhuis>i don't have anything interesting but i have time
15:52:44  <piscisaureus_>bnoordhuis: we do team-wide standups now
15:52:49  * ericktquit (Quit: erickt)
15:52:53  <bnoordhuis>so... that's you and me?
15:53:01  <piscisaureus_>bnoordhuis: so if you want to you can talk on behalf of us
15:53:03  <piscisaureus_>bnoordhuis: yes
15:53:11  <piscisaureus_>bnoordhuis: that's why I ask :-)
15:53:15  <bnoordhuis>haha, okay
15:53:24  <bnoordhuis>guess i'll just get back to work
15:53:41  <bnoordhuis>piscisaureus_: oh wait, what did *you* do?
15:56:21  * loladirojoined
15:57:41  * loladiroquit (Client Quit)
16:13:08  * paddybyersquit (Quit: paddybyers)
16:20:04  * joshthecoderjoined
16:20:07  * stagasjoined
16:30:08  * ericktjoined
16:32:15  * TooTallNatejoined
16:40:05  * AvianFlujoined
16:43:33  * ericktquit (Read error: Operation timed out)
16:46:05  * loladirojoined
16:49:25  * `fogusjoined
16:57:52  * avalanche123joined
17:05:03  * ArmyOfBrucequit (Excess Flood)
17:05:32  * ArmyOfBrucejoined
17:09:51  * avalanche123quit (Quit: Computer has gone to sleep.)
17:14:53  * joshthecoderquit (Quit: Leaving...)
17:20:37  * avalanche123joined
17:21:35  * avalanche123quit (Client Quit)
17:22:40  * AvianFluquit (Quit: AvianFlu)
17:28:34  * AvianFlujoined
17:28:50  <piscisaureus_>nothing, why do you ask?
17:34:16  * ericktjoined
17:38:25  * joshthecoderjoined
17:53:02  * AvianFluquit (Quit: AvianFlu)
17:57:59  * loladiroquit (Quit: loladiro)
18:00:39  * AvianFlujoined
18:08:01  * brsonjoined
18:08:09  * brsonquit (Client Quit)
18:08:27  * brsonjoined
18:11:24  * loladirojoined
18:11:32  * loladiropart
18:13:59  * mcavagejoined
18:17:44  * lohkeyjoined
18:20:41  * AndreasMadsenjoined
18:26:12  <AndreasMadsen>The node changelog lists "cluster: do not use internal server API" and "net: support Server.listen(Pipe)" but both of those where reverted.
18:27:27  <indutny>piscisaureus_: heya
18:28:01  <indutny>piscisaureus_: do you think it'll be hard to make uv_work_t run in one specific thread
18:28:04  <indutny>out of thread pool
18:29:33  <indutny>nvm
18:43:00  * AndreasMadsenquit (Ping timeout: 244 seconds)
19:02:51  * AvianFluquit (Quit: AvianFlu)
19:23:17  * CoverSlide2joined
19:23:26  * CoverSlide2part
19:23:47  * gdawgjoined
19:24:09  * gdawgquit (Client Quit)
19:50:18  * avalanche123joined
19:51:02  * avalanche123quit (Client Quit)
19:58:58  <piscisaureus_>`3rdEden: does it happen with any domain that's already taken?
19:59:09  <piscisaureus_>`3rdEden: or just with port.jit.su?
19:59:18  <piscisaureus_>er, porn.jit.su
19:59:22  <`3rdEden>piscisaureus_ I only added it so you get prompted
19:59:41  <`3rdEden>if you deploy to a non existing domain name, it will not prompt you
20:00:04  <piscisaureus_>ah, right
20:00:11  <piscisaureus_>I have to discuss this with my employer
20:00:26  <piscisaureus_>You know, keyboards ain't free
20:00:31  <piscisaureus_>and the economy is pretty shitty
20:00:53  <`3rdEden>piscisaureus_ i'm suspecting it's probably some odd key combination that killed it
20:01:16  <piscisaureus_>The other day there was this guy that reported that node crashed when he burnt a hole in his macbook
20:01:33  <`3rdEden>=D
20:05:02  * AvianFlujoined
20:05:26  * `3rdEdenquit (Quit: Leaving...)
20:05:53  <saghul>loop->active_handles is supposed to be private, right?
20:06:03  <piscisaureus_>yup
20:06:16  <saghul>piscisaureus_ thanks
20:29:57  <bnoordhuis>$ UV_TCP_SINGLE_ACCEPT=1 out/Release/run-benchmarks tcp_multi_accept4 tcp_multi_accept4
20:29:58  <bnoordhuis>accept4: 29671 accepts/sec (50000 total)
20:29:58  <bnoordhuis> thread #0: 19597 accepts/sec (33025 total)
20:29:58  <bnoordhuis> thread #1: 8407 accepts/sec (14167 total)
20:29:58  <bnoordhuis> thread #2: 1398 accepts/sec (2356 total)
20:29:58  <bnoordhuis> thread #3: 268 accepts/sec (452 total)
20:30:12  <bnoordhuis>maybe that single accept patch isn't working so great...
20:31:28  * brsonquit (Ping timeout: 272 seconds)
20:33:38  <piscisaureus_>bnoordhuis: well, it works great here
20:33:44  <piscisaureus_>:-)
20:33:55  <piscisaureus_>bnoordhuis: what number do you get without?
20:35:24  <bnoordhuis>piscisaureus_: comparable numbers, apparently
20:36:51  <bnoordhuis>piscisaureus_: for your comparison pleasure
20:36:53  <bnoordhuis>$ UV_TCP_SINGLE_ACCEPT=0 out/Release/run-benchmarks tcp_multi_accept8 tcp_multi_accept8
20:36:53  <bnoordhuis>accept8: 26797 accepts/sec (250000 total)
20:36:53  <bnoordhuis> thread #0: 905 accepts/sec (8441 total, 3.4%)
20:36:53  <bnoordhuis> thread #1: 48 accepts/sec (449 total, 0.2%)
20:36:54  <bnoordhuis> thread #2: 18981 accepts/sec (177084 total, 70.8%)
20:36:57  <bnoordhuis> thread #3: 31 accepts/sec (293 total, 0.1%)
20:36:58  <bnoordhuis> thread #4: 6350 accepts/sec (59240 total, 23.7%)
20:37:00  <bnoordhuis> thread #5: 60 accepts/sec (563 total, 0.2%)
20:37:02  <bnoordhuis> thread #6: 351 accepts/sec (3273 total, 1.3%)
20:37:04  <bnoordhuis> thread #7: 70 accepts/sec (657 total, 0.3%)
20:37:06  <bnoordhuis>$ UV_TCP_SINGLE_ACCEPT=1 out/Release/run-benchmarks tcp_multi_accept8 tcp_multi_accept8
20:37:08  <bnoordhuis>accept8: 26552 accepts/sec (250000 total)
20:37:10  <bnoordhuis> thread #0: 7516 accepts/sec (70764 total, 28.3%)
20:37:12  <bnoordhuis> thread #1: 40 accepts/sec (375 total, 0.1%)
20:37:14  <bnoordhuis> thread #2: 36 accepts/sec (337 total, 0.1%)
20:37:16  <bnoordhuis> thread #3: 51 accepts/sec (482 total, 0.2%)
20:37:18  <bnoordhuis> thread #4: 1199 accepts/sec (11291 total, 4.5%)
20:37:20  <bnoordhuis> thread #5: 17351 accepts/sec (163371 total, 65.3%)
20:37:24  <bnoordhuis> thread #6: 86 accepts/sec (808 total, 0.3%)
20:37:26  <bnoordhuis> thread #7: 273 accepts/sec (2572 total, 1.0%)
20:38:04  <piscisaureus_>so, very comparable
20:38:45  <bnoordhuis>yes
20:38:49  <piscisaureus_>BUT
20:38:53  <piscisaureus_>your case is very different
20:39:08  <piscisaureus_>because you are making connections much more slowly than you can accept them
20:39:20  <piscisaureus_>also your benchmarks don't do IO
20:39:27  <CIA-129>libuv: Ben Noordhuis tcp-accept-bench * r57a7de9 / (test/benchmark-list.h uv.gyp test/benchmark-multi-accept.c): bench: add tcp accept benchmarks - http://git.io/cw0wqQ
20:39:38  <bnoordhuis>^ that's the benchmark
20:39:56  <bnoordhuis>and it's true that it doesn't do anything but test raw accept performance
20:40:13  <piscisaureus_>bnoordhuis: I don't even think it's supposed to matter in this scenario
20:40:55  <piscisaureus_>the problem that accept backoff fixes is only relevant when a response can't be generated within one tick
20:41:07  * travis-cijoined
20:41:08  <travis-ci>[travis-ci] joyent/libuv#646 (tcp-accept-bench - 57a7de9 : Ben Noordhuis): The build passed.
20:41:08  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/57a7de9dad7f
20:41:08  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2349288
20:41:08  * travis-cipart
20:42:28  * AvianFluquit (Quit: AvianFlu)
20:45:46  * AvianFlujoined
20:50:57  * ibobrikquit (Quit: ibobrik)
20:58:22  <CIA-129>libuv: Ben Noordhuis tcp-accept-bench * rd4e1469 / test/benchmark-multi-accept.c : bench: add idle delay to tcp_multi_accept{2,4,8} - http://git.io/rJq1Tg
20:58:22  <CIA-129>libuv: Ben Noordhuis tcp-accept-bench * r3758f8e / test/benchmark-multi-accept.c : bench: let client close connection in tcp_multi_accept{2,4,8} - http://git.io/FvydkQ
20:58:37  <bnoordhuis>^ doesn't make much of difference
20:58:56  <bnoordhuis>i need to meditate on it some more
20:59:17  <mmalecki>guru meditation?
21:00:07  * travis-cijoined
21:00:08  <travis-ci>[travis-ci] joyent/libuv#647 (tcp-accept-bench - 3758f8e : Ben Noordhuis): The build passed.
21:00:08  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/57a7de9dad7f...3758f8e16b80
21:00:08  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2349523
21:00:08  * travis-cipart
21:07:59  <piscisaureus_>TooTallNate: doesn't v8 support some sort of arm simulator mode so you can enable snapshots on arm?
21:08:27  <TooTallNate>piscisaureus_: i think it does have some sort of arm simulator but I have no idea how to hook into it
21:08:36  <piscisaureus_>neither do I :-)
21:08:39  <TooTallNate>bnoordhuis might know :)
21:11:00  <bnoordhuis>TooTallNate: arm simulator? yes
21:11:07  <bnoordhuis>what do snapshots have to do with it?
21:11:47  <piscisaureus_>bnoordhuis: you can't cross-compile w/ snapshots
21:12:10  <piscisaureus_>bnoordhuis: but I suppose if you ran mksnapshot using the simulator you could do that for an arm/mips target
21:13:13  <piscisaureus_>TooTallNate: http://code.google.com/p/v8/wiki/CrossCompilingForARM
21:13:45  <piscisaureus_>TooTallNate: that's using the scons-based toolchain but I am pretty sure they ported it to gyp
21:13:52  <piscisaureus_>TooTallNate: I saw it in the commit logs
21:14:58  <TooTallNate>piscisaureus_: ported the simulator?
21:17:57  <piscisaureus_>TooTallNate: ... support simulator builds with gyp ...
21:18:09  <bnoordhuis>TooTallNate, piscisaureus_: you can use qemu in user emul mode for that
21:18:52  <piscisaureus_>really?
21:19:00  <piscisaureus_>It should be much easier
21:19:03  <piscisaureus_>look at this:
21:19:03  <piscisaureus_>http://code.google.com/p/v8/wiki/CrossCompilingForARM#Building_using_scons_with_snapshot
21:20:08  <bnoordhuis>doesn't that depend on the codesourcery toolchain? i wouldn't call that "easier"
21:22:23  * mcavagequit (Remote host closed the connection)
21:23:06  * mcavagejoined
21:32:51  * rendarquit
21:33:57  * brsonjoined
21:52:27  * AvianFluquit (Quit: AvianFlu)
22:04:21  * c4miloquit (Remote host closed the connection)
22:07:45  <piscisaureus_>not fair :-(
22:08:01  <piscisaureus_>1140028 pings (51103.998566 per sec) <-- my windows-epoll branch performs much better than libuv
22:08:11  <piscisaureus_>this is two wpoll_ctl_mod calls per ping
22:08:15  <piscisaureus_>it could even be optimized
22:09:24  <piscisaureus_>oddly enough the release build is about 4 times slowe
22:09:26  * piscisaureus_is puzzled
22:10:42  <piscisaureus_>but then if I bump the number of pingers (tcp connections) to 10000 it is fast again
22:11:38  * hzquit
22:18:59  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:21:50  * TooTallNatejoined
22:23:15  * TheJHquit (Ping timeout: 264 seconds)
22:24:17  * dapquit (Quit: Leaving.)
22:24:47  * dapjoined
22:48:16  * ericktquit (Ping timeout: 252 seconds)
23:08:34  * loladirojoined
23:15:39  * ericktjoined
23:16:38  <bnoordhuis>Remote 'g' packet reply is too long <- gdbserver fail
23:34:47  <piscisaureus_>ooh
23:34:53  <piscisaureus_>100k ping-pongs per sec :-)
23:35:34  * ericktquit (Ping timeout: 245 seconds)
23:47:29  * ericktjoined