00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:03  <isaacs>piscisaureus_: sorry, the last two "update libuv" in node.
00:00:07  * ircretaryjoined
00:00:14  <piscisaureus_>ah
00:00:27  <piscisaureus_>could be related to the rm-ev stuff
00:00:31  <piscisaureus_>you should talk to ben about that
00:00:40  <piscisaureus_>a test case would help very much I think :-)
00:00:41  <isaacs>* bbc3af4 isaacs Revert "deps: upgrade libuv to fc5984f" (31 hours ago)
00:00:41  <isaacs>* a8a12ff isaacs Revert "deps: upgrade libuv to 665a316" (32 hours ago)
00:00:41  <isaacs>* 8ba1bec Ben Noordhuis deps: upgrade libuv to fc5984f (3 weeks ago)
00:00:41  <isaacs>* b6a3b0a Ben Noordhuis deps: upgrade libuv to 665a316 (4 weeks ago)
00:00:41  <isaacs>* a7ac1a1 Ben Noordhuis deps: upgrade libuv to 0ddf9d6 (5 weeks ago)
00:00:56  <isaacs>piscisaureus_: yeah, i'm working on a more minimal test case.
00:01:16  <isaacs>piscisaureus_: right now, only simple/test-tls-pause fails as a result of it, because it's the only case where we do a huge write.
00:01:25  <isaacs>piscisaureus_: but also the benchmark/net-pipe.js breaks
00:01:37  <piscisaureus_>isaacs: the rm-ev stuff is pretty invasive (but important) so bugs are not entirely unexpected in that area
00:02:31  <piscisaureus_>isaacs: so I think we should release 0.10 as soon as streams2 plus some openssl stuff stabilizes
00:02:40  <isaacs>piscisaureus_: yeah, i'm guessing that there's a bug in libuv that is being triggered by streams2 but not by master, so we should work that out
00:02:51  <isaacs>piscisaureus_: agreed. 0.10 will be streams2 plus whatever else we finish by then.
00:03:12  <isaacs>piscisaureus_: but we need to either sort out the libev removal breakage, or roll it back.
00:03:19  <isaacs>i'd much MUCH prefer to actually remove it, and just fix the bug
00:03:26  <piscisaureus_>isaacs: not roll back. Just fix
00:03:31  <piscisaureus_>it's very close to being good
00:03:34  <isaacs>(ie, actually remove libev, not remove the removal)
00:03:41  <isaacs>right
00:03:46  <isaacs>i feel that we are of a similar mind on this
00:03:48  <piscisaureus_>in libuv not much needs to change otherwise except improve the new thread pool
00:03:55  <isaacs>right
00:04:08  <piscisaureus_>isaacs: I discussed this with ben today, it's pretty clear on a detailed level what needs to be done
00:06:07  <isaacs>piscisaureus_: for the treadpool, or for libev removal?
00:06:18  <piscisaureus_>isaacs: threadpool
00:06:21  <piscisaureus_>that's the "other" thing
00:06:39  <isaacs>ah, right.
00:06:40  <isaacs>ok
00:06:42  <isaacs>that sounds great :)
00:20:13  * ArmyOfBrucequit (Excess Flood)
00:20:41  * ArmyOfBrucejoined
00:20:44  * brsonquit (Remote host closed the connection)
00:23:13  * brsonjoined
00:58:48  <isaacs>piscisaureus_: so... i took this tcp-raw.js thing, and i changed it so that it's using a net.js client
00:59:33  <isaacs>piscisaureus_: and, what's really weird, the client ends up in the activeHandles, and the program hangs open
01:00:03  <isaacs>even calling client.unref() doesn't make it stop..
01:00:29  * warzjoined
01:00:29  * warzquit (Changing host)
01:00:30  * warzjoined
01:09:47  <piscisaureus_>isaacs: weird that unref() doesn't work.
01:10:04  <isaacs>piscisaureus_: yeah
01:10:05  <piscisaureus_>isaacs: what does process._getActiveHandles() and process._getActiveRequests show?
01:11:05  <piscisaureus_>isaacs: also, if you call client.close() does it stop
01:11:06  <piscisaureus_>?
01:11:28  <isaacs>i'm calling client.close()
01:11:45  <isaacs>oh, wait, no, i'm not
01:11:46  <isaacs>and yes, it does
01:11:48  <isaacs>{ oncomplete: [Function: afterShutdown] }
01:11:54  <isaacs>that's the diff, it looks like ^
01:12:18  <isaacs> this._handle.close();
01:12:21  <isaacs>that closes it
01:12:40  <piscisaureus_>so it should also exit if you unref it
01:12:55  <piscisaureus_>there may be a bug in that code path somehow
01:13:30  <piscisaureus_>in node 0.8, process.stdin._handle.close() makes node exit
01:13:54  <piscisaureus_>as does process.stdin._handle.unref()
01:14:00  <piscisaureus_>so at least it works sometimes ;-)
01:14:40  <isaacs>right
01:14:49  <isaacs>this is just a plain old tcp client
01:14:50  <isaacs>not stdin
01:15:06  <isaacs>but yeah, it looks like client._handle.close() is being called by master, but not by streams2-net
01:15:17  <piscisaureus_>well, that's a problem :-)
01:15:31  <piscisaureus_>isaacs: if you would readStop() then it would also exit I think
01:15:52  <piscisaureus_>isaacs: but as long as there is a tcp handle that is reading or writing, it wont exit
01:19:07  <isaacs>right
01:19:22  <isaacs>yeah, it's weird. so, i'm calling handle.close(), but then later, it seems to want that to be called again
01:19:34  <piscisaureus_>that's wonly
01:19:40  <piscisaureus_>*wonky
01:20:00  <piscisaureus_>calling close() twice would most likely crash node, not make it work :-)
01:20:18  <piscisaureus_>it'd be really nice if there was a reduced test case that we can use to debug libuv
01:20:31  <deoxxa>isaacs: is that your kitty in your avatar on github? :3
01:21:15  <isaacs>deoxxa: yessir
01:21:19  <deoxxa>meow :3
01:21:33  <deoxxa>i miss my cats now
01:29:21  * lohkeypart
01:31:18  <isaacs>piscisaureus_: interesting. i'm calling shutdown() twice.
01:31:20  <isaacs>piscisaureus_: that's the problem.
01:31:30  <piscisaureus_>'ah
01:31:35  <piscisaureus_>sounds like a libuv bug
01:31:40  <piscisaureus_>or a bug in the binding layer
01:32:03  <piscisaureus_>most likely libuv (by itself) would trigger an assertion fail if you did that
01:32:25  <isaacs>yep, that's the thing
01:32:27  <piscisaureus_>the second shutdown() probably would never actually happen, but as it is a req it keeps the lop alive
01:32:34  <isaacs>yes.
01:32:53  <isaacs>ok, well, this is a bug. tracked it down. all in a day's work :)
01:32:57  <isaacs>now how to write a test for it...
01:33:00  <piscisaureus_>isaacs: the binding layer is pretty fragile atm, e.g. if you use it incorrectly weird stuff happens
01:33:04  <isaacs>yeah
01:33:08  <piscisaureus_>isaacs: that's why people should not :-)
01:33:14  <isaacs>oh, for sure
01:33:17  <isaacs>it's undocumented and awful.
01:33:20  <piscisaureus_>(and possibly a good reason to harden the binding layer)
01:33:23  <isaacs>and insanely verbose
01:33:28  <isaacs>we can make it nice later.
01:33:31  * ericktjoined
01:33:33  <isaacs>it'd be nice if it was prettier
01:33:39  <isaacs>if only to make the node internals easier to read
01:33:41  <piscisaureus_>what is so verbose about that?
01:33:47  <piscisaureus_>s/that/it/?
01:34:22  * pquernaquit (Read error: Operation timed out)
01:35:09  <isaacs>compared with using require('net')?
01:35:12  <isaacs>you're... joking, right?
01:35:26  * mjr_quit (Quit: mjr_)
01:38:28  <isaacs>it's beer time. thanks for your help, piscisaureus_.
01:39:58  * pquernajoined
01:39:59  * pquernaquit (Changing host)
01:39:59  * pquernajoined
01:44:23  * dapquit (Quit: Leaving.)
01:46:47  <piscisaureus_>isaacs: ah, yeah compare to net it's verbose :-)
01:47:02  <piscisaureus_>but it's nice compared to what happens under the hood
01:47:08  * abraxasjoined
01:48:02  <piscisaureus_>that's why I do a talk about require('net').connect(80, 'nyan.cat').pipe(process.stdout), and just superficially discuss the public libuv interface
01:48:21  <piscisaureus_>and, what libuv has to do is still nice compared to what the kernel actually does
01:48:39  <piscisaureus_>welcome to vertical economies :-)
01:50:09  * jmar777joined
01:52:10  * lohkey_joined
01:52:10  * lohkey_quit (Client Quit)
01:53:04  * indexzerojoined
02:04:46  * piscisaureus_quit (Ping timeout: 250 seconds)
02:10:01  * mjr_joined
02:16:23  * joshthecoderquit (Quit: Leaving...)
02:18:14  * rje`macquit (Ping timeout: 240 seconds)
02:18:29  * mjr_quit (Ping timeout: 255 seconds)
02:20:14  * rjequit (Ping timeout: 240 seconds)
02:30:58  * rje`macjoined
02:31:27  * rjejoined
02:35:18  * ArmyOfBrucechanged nick to brucem
02:38:14  * ericktquit (Quit: erickt)
02:39:37  * ericktjoined
02:44:16  * abraxasquit (Remote host closed the connection)
02:56:57  * abraxasjoined
03:05:38  * brsonquit (Ping timeout: 265 seconds)
03:07:20  * sblomquit
03:16:26  * jmar777quit (Remote host closed the connection)
03:23:57  * dapjoined
03:39:50  * warzquit
03:49:38  * kazuponjoined
04:12:34  * loladiroquit (Quit: loladiro)
04:14:33  * ericktquit (Quit: erickt)
04:16:51  * loladirojoined
04:24:34  * lohkeyjoined
04:24:57  * loladiroquit (Quit: loladiro)
04:34:53  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
04:37:11  * mmaleckichanged nick to mmalecki[away]
04:40:10  * loladirojoined
04:51:16  * ryahjoined
05:27:18  * Benviequit
05:27:23  * joshthecoderjoined
05:54:15  * indexzeroquit (Quit: indexzero)
05:58:01  * dapquit (Quit: Leaving.)
06:00:03  * abraxasquit (Read error: Connection reset by peer)
06:00:28  * abraxasjoined
06:08:45  * lohkeyquit (Quit: lohkey)
07:44:52  * `3rdEdenjoined
07:52:21  * stagasjoined
07:54:25  * bnoordhuisjoined
07:55:15  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
07:58:25  * rendarjoined
08:12:05  <bnoordhuis>morning all
08:29:25  * ryahquit (Quit: Lost terminal)
08:36:33  * Benviejoined
08:41:32  * Benviequit
08:41:51  <bnoordhuis>isaacs: still around?
08:42:47  * Benviejoined
08:53:36  <isaacs>bnoordhuis: just barely
08:53:47  <bnoordhuis>isaacs: hey. so about streams2
08:54:11  <bnoordhuis>did you manage to get some kind of reduced test case going?
08:54:17  <isaacs>i got close to one
08:54:29  <isaacs>in the process i figured out that i'm calling shutdown() two times in the client, which is wrong
08:54:34  <isaacs>but i don't think that's the core issue
08:54:47  <bnoordhuis>did you see that test case i posted?
08:54:47  <isaacs>https://gist.github.com/4263245
08:54:57  <isaacs>no, where is it?
08:55:24  <bnoordhuis>one sec, i'll dig it up
08:55:36  <bnoordhuis>isaacs: https://gist.github.com/c9c968b1d8c7579bdff6
08:55:42  <isaacs>so, i'm testing just the raw tcp_wrap interface client and server, and then the tcp_wrap server with net client, adn next i'm going to test the raw client vs net server.
08:56:16  <isaacs>awesome.
08:56:26  <isaacs>that's effectively what i'm doing with the raw business
08:56:31  <bnoordhuis>okay, neat
08:56:41  <bnoordhuis>so it works fine with master but it hangs at n=0 with streams2
08:56:54  <bnoordhuis>for reasons i don't quite comprehend - but hopefully you do
08:57:06  <isaacs>yes.
08:57:11  <isaacs>i don't comprehend them either :)
08:57:19  <isaacs>but hopefully i'll have something reduced more by tomorrow
08:57:36  <isaacs>0.8.16 tomorrow, 0.9.4 thursday
08:57:43  <bnoordhuis>sweet
08:57:51  <bnoordhuis>if i have some time today, i'll look some more at streams2
08:57:52  <isaacs>probably sans-streams2-net, unless we figure it out and it's easy
08:57:55  <isaacs>kk
08:58:22  <MI6>joyent/node: Ben Noordhuis v0.8 * d65832c : fs: fix WriteStream fd leak Close the file descriptor when a write opera (+2 more commits) - http://git.io/n_MfXw
08:59:02  <MI6>joyent/node: isaacs streams2-stdin-wip * 6a2ea26 : streams2: Call read(0) on resume() Otherwise (especially with stdin) you (+2 more commits) - http://git.io/UkwdkA
08:59:10  <isaacs>bnoordhuis: that branch has the current state of things. commit history is a godawful mess ^
08:59:15  <bnoordhuis>hah
09:00:10  <MI6>joyent/node: isaacs streams2-stdin-wip * 249af3b : net: Don't call shutdown more than once - http://git.io/Dy05lg
09:01:30  * sergimjoined
09:02:48  <isaacs>oh, i guess that has the reverts of the libuv changes.
09:03:30  <isaacs>bnoordhuis: ohhh....
09:03:36  <isaacs>bnoordhuis: in your test, you need to do conn.resume()
09:03:50  <isaacs>bnoordhuis: the server is backed up because it's trying to write, and the client isn't reading it
09:03:55  <bnoordhuis>isn't that a change from the old net api?
09:04:01  <isaacs>yes, it is a change.
09:04:03  <bnoordhuis>i thought the idea was to be backwards compatible
09:04:08  <isaacs>yes, that is the idea.
09:04:15  <isaacs>but i'm not sure how that's possible in this case.
09:04:43  <isaacs>we can't solve the "data events come right away ready or not" problem without introducing the "you have to do something to get the flow to happen" problem
09:05:10  <bnoordhuis>ah... that sounds like a pretty big change
09:05:34  <bnoordhuis>the subject of many future angry blog posts
09:05:44  <isaacs>perhaps
09:05:52  <isaacs>all the more reason to get a 0.9 out asap with the change
09:06:03  <isaacs>while we can still cheaply change it
09:07:06  <isaacs>i *suspect* that it's rare that you make a request somewhere, and then don't care about the results.
09:07:29  <bnoordhuis>what if i add a 'data' event listener?
09:07:44  <bnoordhuis>should that auto-trigger resume()?
09:07:46  <isaacs>that'd do it
09:07:47  <isaacs>yes
09:07:55  <isaacs>.pipe() will also make it read() repeatedly until the end
09:08:08  <isaacs> net.createConnection(1234, function() { write(this) ; this.resume() });
09:08:20  <bnoordhuis>right
09:08:29  <isaacs>with that, i get up to 99, and then EPIPE
09:08:39  <isaacs>the EPIPE seems wrong
09:08:47  <bnoordhuis>so i don't know how common that usage pattern is but i've used it in the past for fire-and-forget things
09:08:49  <isaacs>oh, master epipe's a bit, too
09:09:05  <bnoordhuis>the EPIPE is in the server, because the client's closed the connection
09:09:16  <bnoordhuis>so that's okay
09:09:21  <isaacs>also, we have a special case for http.request(). if you don't add a 'response' handler, then it'll resume() it for you, since there's no way you could ever reead it
09:09:29  <isaacs>ok
09:10:24  <isaacs>awesome. with the libuv changes, it hangs forever.
09:10:40  <isaacs>(and with the conn.resume())
09:11:25  <isaacs>so this is a good test.
09:11:41  <bnoordhuis>okay, i'll look into it
09:11:49  <isaacs>here's the tcp-raw.js file using the net.js client: https://gist.github.com/4266289
09:12:30  <isaacs>with a bunch of debuggery as well
09:13:58  <isaacs>both this and tcp-raw.js work fine in streams2.
09:14:19  <isaacs>oh, actually, nvm
09:14:26  <isaacs>this fails with the libuv changes
09:14:39  <isaacs>nvm.
09:14:45  * isaacsis up past his bedtime
09:14:52  <isaacs>it works, just hanging because of the extra shutdown req
09:15:19  <isaacs>so, i think the problem is on the server side, not the client
09:16:07  * isaacszzzzZZzzz
09:17:53  * mmalecki[away]changed nick to mmalecki
09:19:54  <indutny>bnoordhuis: hi
09:20:25  <indutny>bnoordhuis: have you seen latest graceful shutdown pull request https://github.com/joyent/node/pull/4347/files ?
09:49:39  * kazuponquit (Ping timeout: 244 seconds)
09:54:41  * kazuponjoined
09:55:55  * sergimquit (Quit: Textual IRC Client: http://www.textualapp.com/)
09:58:40  * kazuponquit (Remote host closed the connection)
11:05:22  * kazuponjoined
11:05:33  * loladiroquit (Quit: loladiro)
11:08:55  * hzjoined
11:10:18  * roxluquit (Ping timeout: 264 seconds)
11:30:22  <bnoordhuis>indutny: haven't seen it yet
11:33:02  <indutny>ok, np
11:35:03  <indutny>it should be on my desk by the end of day
11:44:52  <indutny>bad joking
11:57:43  <bnoordhuis>it's a pretty good joke though
12:23:42  * abraxasquit (Remote host closed the connection)
12:29:45  * bradleymeckjoined
12:30:08  <bnoordhuis>indutny: what are you working on?
12:30:58  * sgallaghjoined
12:31:14  <indutny>tlsnappy
12:31:18  <indutny>getting it back in action
12:31:25  <indutny>right now it's a little bit fucked
12:31:28  <indutny>but...
12:31:35  <bnoordhuis>watch your language, young man
12:31:37  <indutny>if you want to point me on something else - I'll be ok
12:31:45  <bnoordhuis>no, i was just curious
12:31:49  <indutny>ah, ok
12:31:53  <indutny>so you're on HN again?
12:31:56  <bnoordhuis>what's tlsnappy's issue?
12:32:06  <bnoordhuis>hah no, reworking uv_cancel
12:32:18  <indutny>I think race + incorrect SSL_shutdown
12:32:26  <indutny>or, I've implemented BIO incorrectly
12:32:33  <indutny>it's hard to guess
12:32:44  <indutny>sometimes SSL_read success reading the same sequence
12:32:45  <indutny>multiple times
12:32:52  <indutny>from one BIO
12:33:27  <bnoordhuis>right
12:33:48  <indutny>seems to be a race
12:33:50  <indutny>though, it's pretty hard to debug
12:34:11  <indutny>especially, considering that drd doesn't work on lion
12:34:50  * kazuponquit (Remote host closed the connection)
12:35:11  * sgallaghquit (Remote host closed the connection)
12:35:12  <bnoordhuis>time to switch to a real OS, fedor
12:35:33  * sgallaghjoined
12:35:41  <bnoordhuis>i hear good things about windows
12:45:32  <indutny>hahahaha
13:11:13  * kazuponjoined
13:28:32  * sgallaghquit (Remote host closed the connection)
13:40:25  * jmar777joined
13:42:01  * sgallaghjoined
13:51:35  * stagasquit (Ping timeout: 252 seconds)
13:56:54  * bradleymeckquit (Quit: bradleymeck)
13:57:12  * loladirojoined
13:59:48  * philips_quit (Excess Flood)
14:02:10  * philips_joined
14:17:48  * Raltquit (Remote host closed the connection)
14:39:35  * brucemquit (Ping timeout: 240 seconds)
14:40:03  * brucemjoined
14:40:06  * kazuponquit (Remote host closed the connection)
14:57:02  * loladiroquit (Quit: loladiro)
15:21:28  * bradleymeckjoined
15:24:09  * loladirojoined
15:31:08  * loladiroquit (Quit: loladiro)
15:32:17  * `3rdEdenquit (Quit: banana's)
15:34:00  * indexzerojoined
15:37:23  * kazuponjoined
15:38:35  * roxlujoined
15:39:24  * warzjoined
15:39:25  * warzquit (Changing host)
15:39:25  * warzjoined
15:40:32  * loladirojoined
15:40:49  * piscisaureus_joined
15:45:48  <bnoordhuis>piscisaureus_: mogge bertje
15:57:37  * sblomjoined
15:58:58  * lohkeyjoined
16:02:30  * sblompart
16:04:08  * joshthecoderjoined
16:05:22  * brett_joined
16:07:27  * bnoordhuisquit (Ping timeout: 276 seconds)
16:10:30  <brett_>@bnoordhuis Sven and Brett from Fog Creek (Trello) here on the issues we're having load balancing with Cluster in issue https://github.com/joyent/node/issues/3241, and recent mitigating libuv change commit be2a2176ce25d6a4190b10acd1de9fd53f7a6275 not helping in our case
16:10:53  <brett_>oops, but it looks like you just left
16:11:42  * indexzeroquit (Quit: indexzero)
16:21:23  * AvianFluquit (Remote host closed the connection)
16:22:40  * indexzerojoined
16:27:44  * dapjoined
16:27:50  * stagasjoined
16:36:35  * hzquit
16:47:03  * piscisaureus_quit (Read error: Connection reset by peer)
16:47:47  * piscisaureus_joined
16:47:52  * joshthecoderquit (Quit: Leaving...)
16:50:14  * indexzeroquit (Quit: indexzero)
16:57:02  * lohkeyquit (Quit: lohkey)
17:13:55  * AvianFlujoined
17:23:17  * joshthecoderjoined
17:27:27  * bradleymeckquit (Quit: bradleymeck)
17:27:32  * kazuponquit (Remote host closed the connection)
17:47:27  * indexzerojoined
17:50:22  <txdv>that uv_cancel
17:50:27  <txdv>who is using it?
17:53:52  * `3rdEdenjoined
17:57:55  * kazuponjoined
18:05:07  * dapquit (Quit: Leaving.)
18:05:19  <indutny>everyone :)
18:05:24  <indutny>it's cool
18:06:05  <txdv>I wan't to see a few scenarios
18:06:10  <txdv>Because I want to extend my api
18:06:23  <txdv>This seems like functionality that the user should use
18:06:31  <txdv>And I do not expose request api
18:07:32  * kazuponquit (Ping timeout: 265 seconds)
18:09:26  <piscisaureus_>txdv: nobody uses it yet; it's brand new and it'll have to change :-)
18:10:51  <indutny>especially when bert will start doing windows part
18:32:41  <indutny>why people are using C++1
18:32:43  <indutny>C++11*
18:32:53  <indutny>I can hardly look at it for more than 15 minutes
18:39:52  <roxlu>hi
18:40:15  <indutny>hi
18:40:16  <piscisaureus_>I have to say, it is pretty amazing that this works: https://github.com/joyent/libuv/issues/645
18:40:18  <roxlu>I'm looking into an application where I want to stream 3D coordinates/vertices + a image/texture to about 400 clients
18:40:47  <roxlu>I'm wondering if I need to go for tcp or udp.... someone who can give me some advise?
18:41:08  <indutny>depends
18:41:17  <indutny>how often will it change
18:41:24  <indutny>and how realtime you want it to be
18:41:30  <indutny>tcp is simplier, and works
18:41:41  <indutny>udp is harder, and works a little bit less :)
18:42:00  <roxlu>I want it to be as real time as possible
18:42:11  <roxlu>at least within 500ms delay
18:42:20  <roxlu>it;s on a local wireless network
18:42:41  <roxlu>and the texture is dynamicaly created so to say.. so each X-millis a new line of texture is created
18:42:55  <roxlu>with line of texture, I mean one row of pixels
18:43:00  <roxlu>(a bit like a scanner)
18:43:25  * loladiroquit (Quit: loladiro)
18:43:28  <indutny>use udp
18:43:35  <indutny>but read about jitter
18:43:36  <indutny>and rdp
18:43:49  <indutny>basically, you need to ensure that packets are getting in right order
18:43:54  <indutny>and reorder them otherwise
18:44:19  <indutny>piscisaureus_: oh shit, node.js code in C++
18:44:42  <roxlu>indutny: udp has packet loss too right?
18:44:46  <indutny>yes
18:44:51  <indutny>and out-of-order possibility
18:44:56  <roxlu>yeah
18:45:03  <roxlu>so I need to do a lot of management on that..
18:45:11  <roxlu>would it be doable with tcp?
18:45:47  <indutny>I think yes
18:45:53  <roxlu>the amount of data is not that much, about 640*3 = 1920 bytes
18:45:59  <indutny>sure
18:46:06  <indutny>it'll work just fine
18:46:13  <indutny>especially, considering that you want to fit in 500ms
18:46:25  <roxlu> but I need to send it to 400 clients; soo hmm ~750kb p/s
18:46:38  <roxlu>ok
18:47:02  <roxlu>indutny: so to send it to everyone with tcp, I would need to keep a list of clients and loop over them, right?
18:47:11  <indutny>yes
18:47:11  <roxlu>(when sending data)
18:47:15  <indutny>or
18:47:28  <indutny>yes
18:47:32  <indutny>:)
18:47:36  <roxlu>haha
18:47:38  <roxlu>thanks
18:47:40  <roxlu>or
18:47:43  <roxlu>thanks
18:47:44  <roxlu>;-)
18:48:14  <MI6>joyent/node: isaacs streams2-stdin-wip * b86f2e9 : streams2: Writable only emit 'finish' once - http://git.io/3UJ4vw
18:48:43  <indutny>piscisaureus_: https://github.com/cocaine/cocaine-core/blob/master/include/cocaine/context.hpp#L145
18:48:59  * indutnyyou feel misery when looking at this code too?
18:49:32  <piscisaureus_>variadic templates
18:49:35  * piscisaureus_drools
18:49:41  <indutny>yeeees
18:49:46  <indutny>and not only this
18:49:48  <indutny>traits
18:49:50  <indutny>std::forward
18:50:00  <indutny>look below https://github.com/cocaine/cocaine-core/blob/master/include/cocaine/context.hpp#L185
18:50:21  <indutny>and these guys are complaining that their code isn't compiling everywhere
18:50:43  <piscisaureus_>hahaha
18:50:49  <piscisaureus_>I actually like templates
18:50:56  <indutny>well
18:50:59  <indutny>I hate std
18:51:01  <indutny>:)
18:51:08  <indutny>and variadic stuff kills my brain
18:51:12  <piscisaureus_>and variadic arguments were a big hole in the feature set
18:51:21  <piscisaureus_>(as was the lack of "typename" btw)
18:51:21  <indutny>you know
18:51:28  <indutny>better having big hole
18:51:34  <indutny>that syntax that hard to fit it brain
18:51:50  <indutny>also... I don't think they really need it
18:52:02  <indutny>it can be done in much simplier, ANSI-C way
18:52:10  * TooTallNatejoined
18:52:33  <indutny>and work on more platforms, and do things that're easy to track and understand
18:53:08  <indutny>probably, I'm getting old...
18:53:08  <indutny>idk
18:55:25  <indutny>I like simplicty
18:55:34  <indutny>it makes me feel like I had a good day
18:59:14  * dapjoined
19:03:26  * kazuponjoined
19:03:29  * stagas_joined
19:04:33  * stagasquit (Ping timeout: 244 seconds)
19:04:40  * stagas_changed nick to stagas
19:06:25  <isaacs>ircretary: So, using my tcp-raw.js it works with the libuv changes, and using the net client is fine, but when I use the net server, it fails.
19:06:26  * dapquit (Quit: Leaving.)
19:06:26  <ircretary>isaacs: the was last seen at 2012-09-24T18:13:50.839Z, joining #Node.js
19:06:34  <isaacs>ircretary: tell bnoordhuis So, using my tcp-raw.js it works with the libuv changes, and using the net client is fine, but when I use the net server, it fails.
19:06:35  <ircretary>isaacs: I'll be sure to tell bnoordhuis
19:06:51  <isaacs>ircretary: tell bnoordhuis I'm going to dig into the changes now and try to track it down.
19:06:51  <ircretary>isaacs: I'll be sure to tell bnoordhuis
19:08:17  * kazuponquit (Ping timeout: 255 seconds)
19:08:49  <brett_>Is anyone here familiar enough with multi_accept issues to give the test case I posted at https://github.com/joyent/node/issues/3241#issuecomment-11302935 a once-over and make sure it makes sense?
19:09:30  <brett_>I'm hoping to NOT have bnoordhuis wake up in the morning, check it out, and say 'this is just silly', and not be able to get back to him for several hours.
19:10:04  * brsonjoined
19:12:13  <brett_>@piscisaureus_ I see that you initially opened that issue (https://github.com/joyent/node/issues/3241), and I'm wondering what led you to do that (someone else must have been seeing imbalances?)
19:12:57  <piscisaureus_>brett_: yes, we had this problem at cloud9
19:13:02  <piscisaureus_>on smartos servers
19:13:31  * indexzeroquit (Quit: indexzero)
19:14:12  <brett_>does the the libuv fix mitigate the issue for you?
19:14:27  <piscisaureus_>brett_: we're not using that in production, so I don't know
19:14:51  <piscisaureus_>brett_: we are still using an "older" version of that patch that works for us but (apparently) doesn't work for everyone
19:16:15  <brett_>Got it. And that fix worked with really high traffic like the multi_accept benchmark, or lower traffic more like the siege test at https://github.com/joyent/node/issues/3241#issuecomment-11302935 ?
19:16:44  <brett_>Or some secret option 3?
19:17:00  <piscisaureus_>brett_: eh, it fixed it in production :-)
19:17:07  * bradleymeckjoined
19:17:15  <piscisaureus_>and also when benchmarking with ab
19:17:46  <piscisaureus_>I think it is harder to fix under low-traffic conditions, but it may also not be necessary to fix it then
19:18:08  <brett_>interesting! do you happen to know which commit you are running, or is it a patch that i can see?
19:18:09  <piscisaureus_>it's not a problem if one node process handles all the traffic as long as this node process can keep up
19:18:24  <piscisaureus_>yeah, a sec
19:19:03  <brett_>well, it's a problem for us because we can connect a bunch of websockets, which hang out idle for a long time then can go active simultaneously.
19:19:08  <piscisaureus_>brett_: receiving a call now, will talk back in 15 minutes or so
19:19:13  <brett_>thanks!
19:25:50  * KiNgMaRquit (Quit: ZNC - http://znc.sourceforge.net)
19:29:28  * loladirojoined
19:31:01  * KiNgMaRjoined
19:32:27  <piscisaureus_>brett_: we are running https://github.com/ajaxorg/node/compare/balance
19:32:42  <piscisaureus_>brett_: that is 0.6, btw
19:32:51  <piscisaureus_>a similar patch exists for 0.8, lemme see
19:34:22  <piscisaureus_>brett_: https://github.com/bnoordhuis/libuv/commit/6f77e4597769c80ce43c3c1992a0e3c318cadb5d <-- that may work against 0.8, too
19:38:03  <brett_>piscisaureus_: Thanks, checking it out now!
19:39:23  <txdv>master make test is failing
19:39:53  <txdv>no it isn't
19:39:54  <txdv>i am failing
19:42:29  <isaacs>ohhhhhh
19:42:38  <isaacs>i think i found the issue with streams2-net
19:43:31  <TooTallNate>isaacs: do tell
19:44:25  <isaacs>well... there's a case where i'm checking if state.reading is false (meaning "i should not be reading"), but handle.reading is true (meaning "i am in a readStart() state")
19:44:33  <isaacs>and in that situation, I call handle.readStop()
19:44:37  <isaacs>reasonable, right?
19:44:53  <isaacs>this worked perfectly until the latest libuv changes.
19:45:00  <isaacs>and now, a nextTick makes it work properly.
19:45:15  <isaacs>so, there's a timing issue somewhere.
19:45:49  <isaacs>but i think this is probably just an inconsistency with tcp_wrap binding, and not likely to be something that will pwn other libuv users.
19:48:57  * hzjoined
19:52:45  * jmar777quit (Remote host closed the connection)
19:56:31  * indexzerojoined
19:57:43  <txdv>Do I have to use IPV6AnyAddress when dual stacking?
20:04:15  * kazuponjoined
20:04:16  <piscisaureus_>txdv: yes
20:08:03  <isaacs>ohh... wait, no there's a bug in my test.
20:08:06  <isaacs>i was jsut reading too much.
20:08:07  <isaacs>arg.
20:08:54  * kazuponquit (Ping timeout: 260 seconds)
20:19:13  <isaacs>hm. so it's still a mystery as to why the writeReq.oncomplete is not being called by the net.js code, but IS being called by the raw code...
20:34:59  * loladiroquit (Quit: loladiro)
20:44:33  <isaacs>bnoordhuis, piscisaureus: Wow src/unix/stream.c changed a lot since last i looked at it.
20:50:56  <roxlu>would libuv work on ios?
20:53:36  <TooTallNate>roxlu: last i checked, yes
20:54:15  <roxlu>TooTallNate: thanks, that's great!
20:55:35  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
20:55:50  * joshthecoderjoined
21:01:10  <piscisaureus_>brett_: about your problem. The cluster load balancing is not really designed to distribute requests evenly. The idea is that a node process that is currently less busy has a higher probability of accepting a new connection.
21:01:45  <piscisaureus_>brett_: in your case you may want to do some actual round-robin proxying, but node can't really assist much in that atm
21:01:48  * jmar777joined
21:05:04  * kazuponjoined
21:06:09  <brett_>@piscisaureus: That's fair enough, can you speak to why the option for built-in approximate round robin would not be a goal of Cluster? From my (terribly biased) perspective, it seems like it would be a fairly natural and common preference.
21:06:41  <brett_>For such common cases as lowering latency of a stateless web head, for instance.
21:10:09  * kazuponquit (Ping timeout: 260 seconds)
21:14:32  <brett_>@piscisaureus_: Interestingly enough, it looks like the ajaxorg/node balance branch does about the same thing as vanilla joyent/node master on my test setup with the script from https://github.com/joyent/node/issues/3241#issuecomment-11302935
21:15:03  <brett_>Different OS and all
21:15:48  * Raltjoined
21:18:00  * warzquit
21:18:25  <piscisaureus_>brett_: it has to do with the overall implementation; cluster works by making all node processes "compete" to accept incoming connections. When a process is busy it is less likely to win the race, because it is busy other things
21:18:38  * loladirojoined
21:18:48  * loladiroquit (Client Quit)
21:18:56  * indexzeroquit (Quit: indexzero)
21:18:56  <piscisaureus_>brett_: in theory it *is* possible to get round-robin behaviour with node, but you'd have to understand the node internals fairly well
21:19:23  * `3rdEdenquit (Remote host closed the connection)
21:19:45  <piscisaureus_>brett_: for that you'd have to set up a listening socket in the "master" process, and send accepted sockets over the IPC pipe to child processes
21:20:23  <txdv>would you know how I set ipaddr6_any on c?
21:20:51  <piscisaureus_>txdv: uv_ip6_addr("::1") ? :-)
21:21:04  <piscisaureus_>er
21:21:30  <piscisaureus_>that'd be loopback.
21:21:36  <piscisaureus_>uv_ip6_addr("::")
21:21:47  <txdv>and a port
21:21:50  * bradleymeckquit (Quit: bradleymeck)
21:22:25  <piscisaureus_>txdv: but I think in6addr_any is just specified
21:24:15  <txdv>i fucking hate c
21:24:20  <piscisaureus_>txdv: see http://uw714doc.sco.com/en/SDK_netapi/sockC.TheIPv6sockaddrstructure.html "System selection of source addresses"
21:24:27  <txdv>i can't do anything with this freaking error
21:25:00  <txdv>src/unix/tcp.c:57:12: error: conflicting types for ‘uv__bind’
21:25:00  <txdv>src/uv-common.h:83:5: note: previous declaration of ‘uv__bind’ was here
21:25:27  <brett_>@piscisaureus_: Yes, all of that makes good sense and matches my understanding of the current implementation. I guess that what I would add is that from a Cluster user's perspective (that is, someone writing a Node.js server looking at the interface of Cluster rather than its implementaion), I think it's easy to want "exactly Cluster, except doing round-robin among child processes."
21:25:55  <piscisaureus_>yeah, I get that
21:26:02  * loladirojoined
21:26:21  * loladiroquit (Client Quit)
21:29:16  * loladirojoined
21:30:08  <txdv>ok
21:30:12  <txdv>i got a proposition for the api
21:32:14  <isaacs>piscisaureus_: Aha. it seems like the writeReq.oncomplete doesn't get called if there's only one write in proress.
21:32:17  <isaacs>*progress
21:32:18  <brett_>@piscisaureus_: I'm headed out, Sven just got better results running our test with a 3.7 kernel he built (only about a 3x difference in process page serves over 12 cores), so that's a lot better than the 10x we're seeing in 3.2.0, so we're going to keep cranking on kernel versions and build options for now.
21:32:29  <brett_>Thank you for your help!
21:32:48  <piscisaureus_>isaacs: heuh?
21:33:09  <piscisaureus_>isaacs: if that's true, it's a bug
21:33:12  <isaacs>piscisaureus_: yes.
21:33:14  <isaacs>it's a bug alright :)
21:33:27  <isaacs>that's the difference between what streams2 is ddoing and what master is doing.
21:33:36  <isaacs>master calls handle.writeBuffer() whenever you do a write()
21:33:40  <piscisaureus_>only one write in progress at the same time?
21:33:54  <isaacs>streams2 calls handle.writeBuffer(buf) and then waits for the completion callback before calling it again
21:33:56  <piscisaureus_>that doesn't sound terribly efficient
21:34:01  <piscisaureus_>isaacs: why is that?
21:34:03  <isaacs>yeah, it's not
21:34:05  <isaacs>:)
21:34:10  <isaacs>but it's still a bug.
21:34:13  <piscisaureus_>true
21:34:41  <isaacs>piscisaureus_: the reason why it does that is because it manages the water levels itself in js
21:35:10  <piscisaureus_>isaacs: could you not just look at _writeQueueSize instead of managing water levels in js?
21:35:11  <isaacs>piscisaureus_: and Socket.prototype._write(buf, cb) does effectively this._handle.writeBuffer(buf, cb)
21:35:15  <isaacs>piscisaureus_: yes.
21:35:22  <isaacs>but tha'ts a further optimization
21:35:27  <piscisaureus_>ach so
21:35:32  <isaacs>priority atm is correctness
21:36:25  <isaacs>i got it to fail with my tcp-raw.js self-pipe, but i don't think it even has to do with piping
21:36:32  <isaacs>i'm going to trim it down even more.
21:37:01  <txdv>ACH NE
21:37:25  <txdv>https://github.com/joyent/libuv/pull/651 my proposition on how to rewrite the bind api
21:37:51  <isaacs>oh, wild, so the "one write at a time" only seems to affect the server.
21:39:02  <piscisaureus_>isaacs: I don't doubt you have a problem, but it all seems increasingly unlikely
21:39:06  * TooTallNatequit (Ping timeout: 250 seconds)
21:39:18  <isaacs>piscisaureus_: run this: https://gist.github.com/4271867
21:39:26  <isaacs>piscisaureus_: there is no streamy js code in that at all.
21:39:28  <isaacs>and it should not hang.
21:39:31  <isaacs>but it hangs.
21:39:53  <isaacs>piscisaureus_: the client calls writeBuffer(bigBuf) and then gets the oncomplete
21:40:04  <isaacs>but the server writes the same buffers back, and never gets oncomplete called.
21:40:19  * rendarquit
21:40:33  <piscisaureus_>isaacs: joyent/node@master?
21:40:59  <isaacs>piscisaureus_: yessir
21:41:24  * jmar777quit (Remote host closed the connection)
21:41:29  * loladiroquit (Quit: loladiro)
21:41:44  * stagasquit (Ping timeout: 255 seconds)
21:43:04  * TooTallNatejoined
21:43:52  <txdv>i can't figure out why I do get this conflicting type
21:44:58  <txdv>o now I do
21:46:17  * loladirojoined
21:47:19  <isaacs>piscisaureus_: it looks like it's working when we do writev() but not when we do write()
21:49:12  <txdv>yeah now it even compiles
21:59:59  * sgallaghquit (Ping timeout: 260 seconds)
22:02:47  * benoitcquit (Excess Flood)
22:03:03  <piscisaureus_>isaacs: dunno, I can't really confirm.
22:03:39  <piscisaureus_>isaacs: it seems that the server stops reading it pulled all the data off the socket, which sort of explains why the write never completes
22:04:00  <txdv>piscisaureus_: https://github.com/joyent/libuv/pull/651 <- the tcp binding api would look the same
22:04:34  <piscisaureus_>txdv: why is this a significant improvement?
22:04:44  <isaacs>piscisaureus_: so, previously tcp-raw.js was this: https://gist.github.com/4263245
22:04:54  <isaacs>piscisaureus_: in the pipeSelf, it does:
22:04:54  <isaacs> if (handle.writeQueueSize >= writeWaterMark)
22:04:54  <isaacs> handle.readStop();
22:04:59  <isaacs>and then in afterWrite:
22:05:04  <isaacs>function selfPipeAfterWrite(handle, req) {
22:05:04  <isaacs> if (handle.writeQueueSize < writeWaterMark)
22:05:04  <isaacs> handle.readStart();
22:05:04  <isaacs>}
22:05:24  <isaacs>var writeWaterMark = 1024 * 16;
22:05:32  <isaacs>so... all that I did was remove the if's
22:05:52  * kazuponjoined
22:05:55  * indexzerojoined
22:05:56  <isaacs>piscisaureus_: what happens is that the selfPipe function calls handle.writeBuffer()
22:06:03  <isaacs>piscisaureus_: it also calls readStop()
22:06:11  <isaacs>piscisaureus_: then, it calls readStart in the afterWrite handler
22:06:21  <isaacs>piscisaureus_: but! the afterWrite handler *never happens* if you only have one write in process.
22:06:37  <isaacs>piscisaureus_: the client never calls readStop(0
22:07:36  <isaacs>piscisaureus_: so it *should* always flow through to the client relatively quickly
22:08:51  <txdv>the default behaviour uv_bind6 is to bind in dual stack mode
22:08:59  <txdv>a useless attribute gets removed
22:09:14  <txdv>not significant, but it makes the api clearer
22:09:21  * loladiroquit (Quit: loladiro)
22:09:31  <txdv>this is exactly how I modeled my wrapper api, it was much more sane imo
22:09:42  <txdv>+ no need for UV_UDP_FLAGS any more
22:10:08  * indexzeroquit (Client Quit)
22:10:16  <txdv>and it would be an excuse to make addrr to pointers
22:10:18  * kazuponquit (Ping timeout: 250 seconds)
22:11:12  * benoitcjoined
22:11:52  * Raltquit (Ping timeout: 256 seconds)
22:12:25  <piscisaureus_>txdv: I am not sure I agree... dualstack is essentially a feature of the ipv6 stack; it allows you to create a fully capable ipv6 server and handle ipv4 clients as an afterthought.
22:13:11  <piscisaureus_>isaacs: here's where it stalls: the client writes a big chunk, so the server gets ondata
22:13:23  <piscisaureus_>isaacs: but the server doesn't get *all* client data
22:13:28  <piscisaureus_>isaacs: because the chunk is too big
22:13:57  <txdv>then at least there should be a UV_UDP_DUALSTACK instead of UV_UDP_IPV6ONLY
22:13:58  <piscisaureus_>isaacs: but the server immediately calls readStop when it gets an ondata callback
22:14:16  <txdv>+ uv_bind for now as an flag argument which is always 0
22:14:22  <txdv>has*
22:14:28  <piscisaureus_>isaacs: so the client is never be able to flush all data to the kernel buffer
22:14:44  <piscisaureus_>isaacs: so afterWrite is never called, *because* the write never actually completes
22:15:04  <isaacs>piscisaureus_: it's not the client's afterWrite that isn't getting called.
22:15:11  <isaacs>piscisaureus_: it's the server
22:15:11  <isaacs>s
22:15:18  <piscisaureus_>isaacs: no, it stalls at the client for me
22:15:43  <isaacs>piscisaureus_: right, because the server has stopped reading.
22:15:49  <piscisaureus_>yes
22:15:54  <isaacs>piscisaureus_: because the server's clientHandle has never called readStart()
22:16:06  <piscisaureus_>listening
22:16:07  <piscisaureus_>onconnection
22:16:07  <piscisaureus_>client readstart
22:16:07  <piscisaureus_>CLIENT connect r=true w=true
22:16:07  <piscisaureus_>CLIENT readstart
22:16:07  <piscisaureus_>client write
22:16:07  <piscisaureus_>SERVER ondata 49152 49152 16777216
22:16:08  <isaacs>piscisaureus_: because the server's writeReq.oncomplete (where it calls handle.readStart()) was never called
22:16:08  <piscisaureus_>SERVER readstop
22:16:08  <piscisaureus_>CLIENT ondata 49152 49152 16777216
22:16:09  <piscisaureus_>CLIENT 49152
22:16:10  <LOUDBOT>BEER AND VAGINAS HAHAHA, BALD EAGLES AND SHIT, FUCK YES!
22:16:19  <isaacs>piscisaureus_: like how i tricked you into louding? ;)
22:16:31  <piscisaureus_>txdv: I do agree that opt-in dualstack makes for a nicer api
22:16:52  <isaacs>piscisaureus_: so. if the server's writeReq completes, then the server will call readStart() again
22:17:07  <isaacs>piscisaureus_: the client is never readStop()ing, so it should continue to flow without problems.
22:17:08  <piscisaureus_>but the server doesn't write
22:17:16  <piscisaureus_>isaacs: I don't see the server writing here...
22:17:42  <isaacs>piscisaureus_: yeah, it does: https://gist.github.com/4271867#file-tcp-raw-js-L84-L97
22:18:02  <isaacs>piscisaureus_: the server writes back whatever it reads
22:18:18  <isaacs>piscisaureus_: every time it gets a chunk, it stops reading, writes it, and when the write is completed, it readStart()s again
22:18:36  <isaacs>piscisaureus_: otherwise it'd fail with the libuv changes reverted, and it succeeds there.
22:18:48  <isaacs>serverHandle.onconnection = onconnection;
22:19:22  * loladirojoined
22:19:36  <isaacs>then in the connection handler, it does: clientHandle.onread = onread(selfPipe)
22:19:57  <isaacs>onread() returns a function that checks if it's a valid chunk, blah blah blah, then calls the supplied function
22:20:35  <isaacs>in this case, the supplied function is selfPipe, which calls writeBuffer(chunk), calls handle.readStop(), and in the writeReq.oncomplete, calls handle.readStart()
22:21:00  <txdv>but if you use dualstack, you use always ip6addrany
22:21:10  <piscisaureus_>txdv: yes
22:21:17  <txdv>perfect scenario
22:26:18  <txdv>so if I want to add UV_TCP_DUALSTACK I will have to create yet another enum
22:26:22  <txdv>as opposed to just a function
22:27:45  <isaacs>txdv: you're stealing my piscisaureus_ time ;P
22:28:17  <txdv>well then finish your buissness first and release the resource then by pming me
22:28:24  <isaacs>hahah
22:28:37  <isaacs>txdv: but i only have one issue, so i don't think the afterWrite will ever get called.
22:28:55  <isaacs>(luckily for us bertje doesn't run on libuv)
22:29:03  * loladiroquit (Quit: loladiro)
22:29:49  <txdv>you meant to address that to someone else, or didn't you?
22:31:47  <isaacs>txdv: bertje == piscisaureus_
22:35:47  <piscisaureus_>txdv: well your design criteria may be different but I think fewer functions is better.
22:35:55  <piscisaureus_>txdv: what's wrong with enum?
22:36:30  <txdv>it is one additional function which makes it even easier to use dualstack mode because it has only a port
22:36:36  <txdv>as an argument
22:39:23  * isaacsgot pre-empted
22:39:26  * isaacs:(
22:39:27  <LOUDBOT>I CAN DRINK IF I WANT TO, I CAN LEAVE BEER BOTTLES BEHIND
22:39:58  <isaacs>LOUDBOT: TRYING TO CHEER ME UP? I THOUGHT YOU GAVE UP USELESS TASKS FOR LOUDMAS
22:39:59  <LOUDBOT>isaacs: OH GOD YOU EAT ORGANS AND BONE MARROW RIGHT"
22:40:07  <isaacs>mmmmm bone marrow
22:41:08  * indexzerojoined
22:41:17  * roxluquit (Quit: Page closed)
22:42:48  <piscisaureus_>isaacs: right, I think I am on to something
22:43:02  <isaacs>starting 0.8.16
22:43:04  <isaacs>releasing tomorrow
22:43:13  <piscisaureus_>txdv: well, you should probably do what we do when we deal with windows/linux/blablaos
22:43:25  <txdv>what
22:43:36  <piscisaureus_>txdv: swear a lot, call those guys idiots and plaster it over with the api that we like
22:43:52  <txdv>xD
22:45:14  <MI6>joyent/node: isaacs created branch v0.8.16-release - http://git.io/5RMPZQ
22:45:50  <isaacs>piscisaureus_: is it possible that it's trying to call the writeReq.oncomplete before I've added it?
22:45:51  * loladirojoined
22:46:00  <piscisaureus_>isaacs: that shouldn't happen
22:46:03  <piscisaureus_>that would also be a bug
22:46:05  <isaacs>ok
22:46:09  <isaacs>i'm not sure i could even test that
22:46:36  * joshthecoderquit (Quit: Leaving...)
22:49:10  <isaacs>piscisaureus_: even in the tcp-raw that works (by doing multiple writes) many of the oncompletes dont' get called.
22:50:24  * loladiroquit (Ping timeout: 256 seconds)
22:50:34  <isaacs>heh, actually no oncompletes are called.
22:50:40  <isaacs>it's just that it isn't waiting for htem
22:52:08  * indexzeroquit (Quit: indexzero)
22:54:48  <isaacs>i take that back.
22:54:53  <isaacs>operator error.
22:56:38  <txdv>piscisaureus_: (flags & UV_UDP_DUALSTACK) == 0 or !(flags & UV_UDP_DUALSTACK)
22:57:31  <piscisaureus_>txdv: the latter
23:07:10  * kazuponjoined
23:07:47  <piscisaureus_>isaacs: yeah, i can confirm something odd is going on. The uv tcp handle is placed in the pending queue after the write completes, but then somehow disappears
23:08:18  * indexzerojoined
23:09:09  <isaacs>piscisaureus_: that's so validating to hear.
23:09:14  <txdv>IPV6_V6ONLY is only defined if the system supports dual stack?
23:09:27  <isaacs>piscisaureus_: in the meantime, i'm going to refactor to push more than just one write to libuv
23:09:38  <isaacs>piscisaureus_: will that writeQueueBuffer blow up at some point?
23:10:01  <piscisaureus_>isaacs: you mean, is there a limit to how much you can write?
23:10:03  <isaacs>piscisaureus_: ie, how many bytes can i shove into libuv before i start having problems?
23:10:06  <isaacs>yeah
23:10:12  <piscisaureus_>isaacs: just do it :-0
23:10:18  <isaacs>k :)
23:10:27  <isaacs>i figure it's bound by process operating system whatever whatever.
23:10:32  <isaacs>and that's limiting Buffers anyway, so meh
23:10:38  <piscisaureus_>isaacs: no, it's not limited by the OS
23:10:52  <piscisaureus_>it's limited by how much memory one has
23:11:00  <isaacs>right
23:11:02  <isaacs>limited by the system
23:11:48  * kazuponquit (Ping timeout: 248 seconds)
23:14:09  <txdv>this V6ONLY is so stupid, they should have made a V6DUALSTACK option instead
23:14:17  <txdv>dafuq is wrong with these people
23:14:23  * indexzeroquit (Quit: indexzero)
23:14:36  <piscisaureus_>txdv: THAT'S THE SPIRIT
23:14:43  <piscisaureus_>isaacs: ok, I know what happens
23:14:54  <txdv>now I have to write a shitload of ifdefs
23:15:16  <piscisaureus_>isaacs: the problem occurs when you (a) write something that fits in the kernel buffer immediately and (b) call readStop immediately after
23:16:49  <txdv>I don't but it was confusing to figure how it would behave on different platforms
23:17:15  * indexzerojoined
23:18:51  <isaacs>piscisaureus_: now a race to see whether you can fix it before i work around it :)
23:18:54  * indexzeroquit (Client Quit)
23:19:04  <isaacs>piscisaureus_: but 0.9.4 goes out tomorrow (along with 0.8.16)
23:19:14  <isaacs>piscisaureus_: actually, i dunno, maybe friday
23:19:19  <isaacs>or monday
23:19:29  <piscisaureus_>isaacs: I know how to fix it, but I'm going to need Ben's second opinion on it
23:19:33  <piscisaureus_>since he wrote all that stuff
23:19:37  <isaacs>we should land streams2-net asap even if it's a bit sloppy
23:19:39  <isaacs>piscisaureus_: understood
23:19:49  <isaacs>piscisaureus_: you might still beat me to it :)
23:20:38  * indexzerojoined
23:23:21  * isaacsaway for a bit
23:26:27  <piscisaureus_>isaacs: ok, have fix :-)
23:27:47  * indexzeroquit (Quit: indexzero)
23:27:50  * warzjoined
23:27:50  * warzquit (Changing host)
23:27:50  * warzjoined
23:30:48  * loladirojoined
23:35:04  <MI6>joyent/libuv: piscisaureus created branch reviewme - http://git.io/ijIKow
23:36:14  <txdv>piscisaureus_: https://github.com/joyent/libuv/pull/652
23:36:40  <txdv>A wip
23:36:53  * travis-cijoined
23:36:53  <travis-ci>[travis-ci] joyent/libuv#945 (reviewme - bf6f302 : Bert Belder): The build passed.
23:36:53  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/bf6f30218a23
23:36:53  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3637444
23:36:53  * travis-cipart
23:40:30  <piscisaureus_>txdv: okay, i think I agree with the change in principle
23:41:17  <piscisaureus_>txdv: I have to find out what the default behaviour is for different unices. Maybe we should just always try to enable or disable it explicitly
23:43:23  <txdv>imo my other API proposal is better
23:43:32  <txdv>but that can be pushed later
23:43:40  <txdv>this thing is better than the default behaviour anyway
23:44:22  <piscisaureus_>txdv: http://stackoverflow.com/questions/2693709/what-was-the-motivation-for-adding-the-ipv6-v6only-flag
23:45:20  * brucemquit (Excess Flood)
23:45:51  * brucemjoined
23:46:01  * jmar777joined
23:46:31  <txdv>to piss entire generations yet to come off
23:47:03  <txdv>i found that one but it has no good answe
23:47:58  <txdv>adding that options doesn't break code, if they added it together with the entire ipv6
23:48:59  <txdv>and since bsd has ipv6 and it doesn't have this option, it breaks code that was written for linux and someone tried to port it to bsd
23:49:06  <txdv>bsd doesn't have ipv6
23:50:18  <txdv>no bsd has ipv6, but it doesnt have this option
23:50:39  <txdv>it's a brainfuck option
23:51:05  <piscisaureus_>txdv: don't worry about it too much. People don't use it anyway ;-)
23:51:11  <txdv>I use it
23:51:19  <txdv>I think it is an awesome option
23:51:25  <txdv>my bindings support it
23:51:28  <piscisaureus_>well but you are building a platform
23:51:37  <piscisaureus_>do you actually have a use for it?
23:52:39  <txdv>no
23:53:05  <txdv>i don't have a server with an ipv6 address
23:53:16  <txdv>only the testcase
23:53:19  <piscisaureus_>haha
23:53:47  <txdv>so what about adding dualstack to uv_tcp
23:54:26  <txdv>either I add an argument to uv_tcp_bind just like in uv_udp_bind or we do it like in my first proposal with the 3 functions
23:54:41  * deoxxachanged nick to [mlg]d30xx4[mlg]
23:56:18  * indexzerojoined
23:57:42  * indexzeroquit (Client Quit)
23:57:49  <txdv>in languages with overloads you can hide everything away into one function name
23:58:24  <txdv>so the I don't care too much how the c code looks like
23:58:30  <txdv>just tell me for what option to go