00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:01:24  * avalanche123quit (Remote host closed the connection)
00:07:40  * a_lejoined
00:09:20  * c4milojoined
00:13:52  * c4miloquit (Ping timeout: 240 seconds)
00:18:18  * euoiaquit (Ping timeout: 240 seconds)
00:29:12  * a_lequit (Remote host closed the connection)
00:29:47  * a_lejoined
00:34:44  * avalanche123joined
00:38:57  * avalanche123quit (Ping timeout: 245 seconds)
00:41:12  * c4milojoined
00:58:51  * euoiajoined
01:39:26  * AvianFluquit (Remote host closed the connection)
01:42:52  * Left_Turnquit (Remote host closed the connection)
01:45:16  * AvianFlujoined
02:09:19  * wavdedjoined
02:09:19  * wavdedquit (Client Quit)
02:16:20  * petka_quit (Quit: Connection closed for inactivity)
02:19:13  * kazuponjoined
02:35:22  * kazuponquit (Remote host closed the connection)
02:44:55  * AvianFluquit (Remote host closed the connection)
02:48:25  * brsonquit (Quit: leaving)
02:49:39  * AvianFlujoined
02:58:49  * kazuponjoined
03:06:57  * daviddiasjoined
03:08:17  * AvianFlu_joined
03:08:44  * AvianFluquit (Disconnected by services)
03:08:46  * AvianFlu_changed nick to AvianFlu
03:45:42  * TooTallNatejoined
04:23:41  * seldoquit
04:25:46  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
04:28:26  * yunongjoined
04:30:15  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:32:00  * sh1mmerjoined
04:38:14  * sh1mmerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
04:38:24  * AvianFluquit (Remote host closed the connection)
04:44:42  * sh1mmerjoined
04:45:35  * AvianFlujoined
04:47:42  * AvianFluquit (Client Quit)
04:47:54  * AvianFlujoined
04:49:35  * sh1mmerquit (Client Quit)
04:56:45  * avalanche123joined
05:02:12  * thlorenzjoined
05:06:53  * thlorenzquit (Ping timeout: 255 seconds)
05:09:07  * c4miloquit (Remote host closed the connection)
05:17:49  * yunongquit
05:22:47  * AvianFluquit (Remote host closed the connection)
05:29:07  * avalanche123quit (Remote host closed the connection)
05:30:34  * kazupon_joined
05:31:04  * kazuponquit (Ping timeout: 260 seconds)
05:41:48  * seishunjoined
05:55:28  * wolfeidaujoined
06:24:12  * Left_Turnjoined
06:26:06  * MI6quit (Ping timeout: 255 seconds)
06:26:32  * ircretaryquit (Ping timeout: 255 seconds)
06:32:26  * c4milojoined
06:32:59  * ircretaryjoined
06:33:28  * MI6joined
06:36:53  * c4miloquit (Ping timeout: 255 seconds)
06:42:03  * seishunquit (Ping timeout: 240 seconds)
06:50:42  * kazupon_quit (Remote host closed the connection)
06:53:24  * rendarjoined
07:14:37  * dsantiagojoined
07:16:32  * inolenquit (Quit: Leaving.)
07:29:02  * avalanche123joined
07:33:33  * avalanche123quit (Ping timeout: 240 seconds)
07:43:03  * dsantiagoquit (Ping timeout: 240 seconds)
07:53:44  * dsantiagojoined
07:56:08  * dsantiagoquit (Max SendQ exceeded)
07:57:27  * dsantiagojoined
07:57:39  * petka_joined
08:06:21  * Soarez|afkchanged nick to Soarez
08:14:47  * bajtosjoined
08:38:12  * dsantiagoquit (Ping timeout: 260 seconds)
08:41:21  * dsantiagojoined
08:50:55  * kazuponjoined
09:10:38  * euoiaquit (Ping timeout: 240 seconds)
09:18:20  * kellabyte_changed nick to kellabyte
09:18:41  * kellabytequit (Changing host)
09:18:42  * kellabytejoined
09:18:42  * kellabytequit (Changing host)
09:18:42  * kellabytejoined
09:19:18  * guybrushquit (Excess Flood)
09:20:07  * guybrushjoined
09:31:13  * euoiajoined
09:37:49  * bajtosquit (Quit: bajtos)
09:38:15  * rmgquit (Remote host closed the connection)
09:41:26  * bajtosjoined
09:45:52  * bajtosquit (Ping timeout: 250 seconds)
09:51:51  * kazuponquit (Remote host closed the connection)
09:56:06  * bajtosjoined
09:59:58  * dignifiedquirejoined
10:00:48  * bajtosquit (Ping timeout: 260 seconds)
10:00:50  * kazuponjoined
10:08:48  * c4milojoined
10:08:57  * rmgjoined
10:13:03  * c4miloquit (Ping timeout: 240 seconds)
10:15:12  * rmgquit (Ping timeout: 240 seconds)
10:39:05  * mikealjoined
10:49:34  * janjongboomjoined
10:51:14  * mikealquit (Quit: Leaving.)
10:53:39  * guybrushquit (Excess Flood)
10:54:38  * guybrushjoined
10:56:47  * bajtosjoined
11:01:22  * bajtosquit (Ping timeout: 240 seconds)
11:16:22  * mrvisserjoined
11:28:52  * kazuponquit (Remote host closed the connection)
11:31:31  * Soarezchanged nick to Soarez|afk
11:33:27  * Soarez|afkchanged nick to Soarez
11:34:05  * avalanche123joined
11:34:54  * Soarezchanged nick to Soarez|afk
11:36:21  * wolfeidauquit (Remote host closed the connection)
11:38:32  * avalanche123quit (Ping timeout: 245 seconds)
11:44:20  * bajtosjoined
11:49:19  * bajtosquit (Ping timeout: 256 seconds)
11:49:58  * stagasjoined
11:57:08  * c4milojoined
12:01:52  * c4miloquit (Ping timeout: 245 seconds)
12:08:04  * AlexisMocha_quit (Read error: Connection reset by peer)
12:08:30  * AlexisMochajoined
12:22:58  * mrvisserquit (Remote host closed the connection)
12:28:33  * gargsmsjoined
12:32:17  * mrvisserjoined
12:42:04  * bajtosjoined
12:46:46  * bajtosquit (Ping timeout: 264 seconds)
12:51:58  * euoiaquit (Ping timeout: 240 seconds)
12:54:26  * stagas_joined
12:54:41  * stagasquit (Ping timeout: 250 seconds)
12:54:50  * stagas_changed nick to stagas
13:02:42  * gargsmsquit (Ping timeout: 240 seconds)
13:15:06  * gargsmsjoined
13:22:25  <trevnorris>jcrugzz: yeah. let's talk some time. just been really busy the last week.
13:22:33  <trevnorris>indutny: have a sec?
13:23:19  <indutny>yep
13:23:20  <indutny>heya
13:23:23  <indutny>what's up?
13:24:35  <trevnorris>indutny: you said in your node-spdy that you somehow hijacked the incoming data from an incoming http request before it was sent to the http parser?
13:28:55  * gargsmsquit (Ping timeout: 250 seconds)
13:29:09  <indutny>trevnorris: hm...
13:29:10  <indutny>yes
13:29:17  <indutny>but not exactly
13:29:21  <indutny>I do create an http request myself
13:29:29  * bajtosjoined
13:29:30  <indutny>so it is almost like that :)
13:30:31  * pdurbinpart ("WeeChat 0.4.0")
13:31:06  * Soarez|afkchanged nick to Soarez
13:33:16  <indutny>sorry, brb
13:35:00  * euoiajoined
13:41:18  * euoiaquit (Ping timeout: 240 seconds)
13:41:20  * gargsmsjoined
13:42:21  * euoiajoined
13:45:11  * c4milojoined
13:51:55  <trevnorris>Can anyone tell me why the following would cause a segfault? https://gist.github.com/trevnorris/a75a0a05550f3e2e3708
13:54:46  * dignifiedquirequit (Quit: dignifiedquire)
13:56:15  <nathan7>trevnorris: *where* does the segfault occur?
13:57:11  * piscisaureusjoined
13:59:27  <trevnorris>nathan7: here's a bt: https://gist.github.com/trevnorris/a75a0a05550f3e2e3708#file-backtrace-log
14:00:27  <trevnorris>i'm simplifying it now.
14:07:35  <trevnorris>hm. think it has something to do w/ using args. it doesn't segfault if I do Object::New(Isolate*)
14:10:27  <trevnorris>forget that. if I run the function twice it still fails.
14:10:40  <trevnorris># Fatal error in ../deps/v8/src/global-handles.cc, line 335
14:10:46  <trevnorris>SUCK IT!
14:10:46  <LOUDBOT>THIS IS NOT MY BEAUTIFUL WIFE! THIS IS NOT MY BEAUTIFUL HOUSE!
14:13:31  * AvianFlujoined
14:21:58  * euoiaquit (Ping timeout: 240 seconds)
14:23:12  * euoiajoined
14:25:41  <trevnorris>strange. when I put it in a class it seems to work. whatever.
14:39:45  * piscisaureusquit (Ping timeout: 255 seconds)
14:40:26  * AvianFluquit (Remote host closed the connection)
14:42:08  * kazuponjoined
14:47:38  * euoiaquit (Ping timeout: 240 seconds)
14:48:45  * euoiajoined
14:50:38  * mrvisserquit (Remote host closed the connection)
14:53:13  * rmgjoined
14:55:12  * piscisaureusjoined
15:00:14  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:00:58  * euoiaquit (Ping timeout: 240 seconds)
15:07:15  <tjfontaine>trevnorris: because you only allocated the size of a pointer
15:07:23  <tjfontaine>trevnorris: malloc(sizeof(*async_call)));
15:07:56  <tjfontaine>oh I thoguht that was the type name
15:08:01  <tjfontaine>sorry still drinking my coffee
15:08:33  <tjfontaine>hmm no I'm still skeptical of that line
15:09:20  <piscisaureus>hello
15:09:33  <nathan7>Hey piscisaureus
15:10:06  <tjfontaine>so I wonder what args.This() is in that case, when he said "class" he must have meant js instance
15:10:35  * gargsmsquit (Remote host closed the connection)
15:14:43  <piscisaureus>tjfontaine: trevnorris: use reinterpret_cast?
15:16:05  <tjfontaine>piscisaureus: I think it's just a red herring there, looking at the stack trace it's the args.This() failing an internal state check
15:16:33  <piscisaureus>possibly
15:17:04  <tjfontaine>the malloc style is not what I would prefer, in this particular case I'd just as soon use `new AsyncCall`
15:17:19  <tjfontaine>and that may be what the problem is, the Persistent's constructor not running
15:17:20  <piscisaureus>I agree with that.
15:17:26  <piscisaureus>but it looks fine
15:17:28  <piscisaureus>oh wait
15:17:37  <piscisaureus>the constructor for Persistent<Object> is also not getting called
15:17:42  <tjfontaine>right
15:18:06  <tjfontaine>malloc + struct is "ok" so long as you're not using C++ types
15:18:13  <tjfontaine>well classes in your struct
15:18:17  <piscisaureus>trevnorris: ok - so use 'new AsyncCall'
15:18:25  <piscisaureus>tjfontaine: so it's also not the This() call that's throwing.
15:18:32  <tjfontaine>I think that's what he meant when he said "when I use a class"
15:18:38  * AvianFlujoined
15:18:39  <piscisaureus>tjfontaine: it's the attempt that Persistent makes to release it's earlier contents
15:18:49  <piscisaureus>makes sense
15:21:19  * janjongboomjoined
15:25:53  * euoiajoined
15:30:35  * c4miloquit (Remote host closed the connection)
15:32:19  * c4milojoined
15:52:00  * mrvisserjoined
15:52:03  * seishunjoined
15:54:51  * andrehjrjoined
15:54:58  * kazuponquit (Remote host closed the connection)
15:59:30  * dignifiedquirejoined
16:02:22  * AvianFluquit (Remote host closed the connection)
16:02:51  * AvianFlujoined
16:03:13  <seishun>is it guaranteed that a module that works with 0.11.12 will work with 0.12?
16:03:32  * AvianFluquit (Remote host closed the connection)
16:03:55  * AvianFlujoined
16:06:42  * daviddiasjoined
16:15:55  * a_le_joined
16:16:26  <trevnorris>piscisaureus / tjfontaine: thanks. it didn't occur to me that it would need to run a constructor.
16:16:55  <trevnorris>i mean, that running .Reset(Isolate*, Handle<T>) wasn't enough
16:18:07  * a_lequit (Ping timeout: 245 seconds)
16:18:48  <trevnorris>piscisaureus: dude, I swear there was an issue about opening multiple fs streams, since it would place a mutex on the worker threads, and that it would block I/O in some way.
16:19:02  <trevnorris>must be loosing my mind, but can't find it for the life of me.
16:19:19  <piscisaureus>trevnorris: on mac you mean?
16:19:30  <trevnorris>is it only on mac?
16:19:45  <piscisaureus>trevnorris: the thing you spoke to your apple friend about. Yes that's mac only.
16:19:53  <trevnorris>ah, ok.
16:20:10  <trevnorris>so i'm not going completely insane.
16:20:20  <piscisaureus>trevnorris: https://github.com/joyent/libuv/blob/06c60e9662fea752d77237857bbf2c9ea5889a00/src/unix/fs.c#L587-L590
16:20:38  <trevnorris>thanks.
16:21:21  <trevnorris>so on linux it just opens the fd, and places a mutex on the worker thread when data needs to be written?
16:21:50  * inolenjoined
16:21:56  <trevnorris>i mainly ask because if I do an strace -c and see a lot of futex's that usually indicates either a lot of fs or a lot of dns resolution.
16:24:08  <trevnorris>piscisaureus: also, what do you think about adding pthread_exit() / ExitThread() support to libuv ?
16:24:25  <piscisaureus>trevnorris: you want my honest answer? :)
16:24:32  <trevnorris>yes
16:24:41  <trevnorris>which probably means no. :)
16:24:45  <piscisaureus>trevnorris: ok. You shouldn't use either functions.
16:25:00  <piscisaureus>trevnorris: I don't care if you add it to libuv as long as you don't actually use it
16:25:05  <trevnorris>hahaha
16:25:26  <trevnorris>what? don't like the idea of spawning a thread to run the event loop, then closing the main thread?
16:25:47  * Ralithquit (Ping timeout: 264 seconds)
16:26:53  <piscisaureus>trevnorris: exiting a thread by means of exitThread
16:27:03  <piscisaureus>if you want to exit a thread, just make sure you return from the threadmain function
16:27:22  <piscisaureus>trevnorris: I don't think pthread_exit works nicely with c++ destructors and all that
16:29:47  <trevnorris>interesting. ok.
16:30:28  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
16:33:50  * dignifiedquirequit (Quit: dignifiedquire)
16:34:40  * a_le_quit (Remote host closed the connection)
16:34:50  * piscisaureus_joined
16:37:38  * piscisaureusquit (Ping timeout: 255 seconds)
16:42:52  * daviddiasjoined
16:43:12  * a_lejoined
16:43:40  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:44:50  * guilleiguaran__part
16:46:36  <dirkson>Ok, so I've successfully built a network stack on top of libuv. It replaces a libenet stack in my video game. Since this implementation has been in place, I've had zero problems not caused by me. This was.... not true of libenet. Just wanted to say I appreciate the lack of bugs ^.^
16:47:23  * a_lequit (Ping timeout: 256 seconds)
16:48:10  <saghul>dirkson: we can add bugs if you need them :-P
16:50:37  * AlexisMochaquit (Ping timeout: 245 seconds)
16:50:52  * AlexisMochajoined
16:51:00  * TooTallNatejoined
16:55:20  * jgijoined
17:08:40  * brsonjoined
17:09:36  * Ralithjoined
17:11:07  * bajtosquit (Quit: bajtos)
17:11:51  * sblomjoined
17:12:35  <qard-appneta>There's always bugs. They just get better at hiding.
17:14:09  * avalanche123joined
17:16:22  * dignifiedquirejoined
17:18:24  * dap_1joined
17:28:02  * daviddiasquit (Quit: Textual IRC Client: www.textualapp.com)
17:28:37  * bajtosjoined
17:30:07  * Soarezchanged nick to Soarez|afk
17:39:45  * daviddiasjoined
17:58:16  * daviddiasquit (Quit: Textual IRC Client: www.textualapp.com)
18:03:21  * dignifiedquirequit (Quit: dignifiedquire)
18:06:00  * daviddiasjoined
18:08:56  * daviddiasquit (Client Quit)
18:10:57  <brockfredin>I'm the main creator of bugs anywhere. :)
18:12:19  * daviddiasjoined
18:18:52  * sh1mmerjoined
18:21:35  * dignifiedquirejoined
18:27:18  <chrisdickinson>tjfontaine: had a question re: splitting core modules into private core modules (a la stream & _stream_readable) -- when is it considered okay to do that?
18:27:53  * yunongjoined
18:28:03  <chrisdickinson>in specific, I was looking at maybe splitting net up into _net_common, _net_socket, _net_server or something along those lines.
18:34:20  * andrehjrquit (Quit: Computer has gone to sleep.)
18:34:51  * dsantiagoquit (Read error: Connection reset by peer)
18:34:57  * avalanche123quit (Remote host closed the connection)
18:35:16  * dsantiag_joined
18:35:31  * avalanche123joined
18:36:06  * avalanche123quit (Remote host closed the connection)
18:36:18  * avalanche123joined
18:36:20  * petka_quit (Quit: Connection closed for inactivity)
18:37:25  * dsantiag_quit (Max SendQ exceeded)
18:46:52  * dsantiagojoined
18:47:37  * bajtosquit (Quit: bajtos)
18:50:58  * euoiaquit (Ping timeout: 240 seconds)
18:51:18  * rendarquit (Ping timeout: 255 seconds)
18:51:18  * andrehjrjoined
18:57:04  * rendarjoined
18:57:14  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
19:02:38  * euoiajoined
19:12:55  * avalanche123quit (Remote host closed the connection)
19:16:41  * avalanche123joined
19:16:41  * avalanche123quit (Remote host closed the connection)
19:16:56  * avalanche123joined
19:18:41  * a_lejoined
19:29:19  * c4miloquit (Remote host closed the connection)
19:29:27  * jgiquit (Ping timeout: 256 seconds)
19:30:58  * guybrushquit (Excess Flood)
19:31:38  * guybrushjoined
19:31:40  * c4milojoined
19:32:02  * Soarez|afkchanged nick to Soarez
19:43:48  * daviddiasjoined
19:44:03  * kenperkinsquit (Quit: Computer has gone to sleep.)
19:51:47  * Soarezchanged nick to Soarez|afk
19:52:09  * mrvisserquit (Remote host closed the connection)
19:52:18  * euoiaquit (Ping timeout: 240 seconds)
19:52:57  * mrvisserjoined
19:57:12  * mrvisserquit (Ping timeout: 260 seconds)
20:04:02  * Soarez|afkchanged nick to Soarez
20:08:32  * petka_joined
20:08:45  * jgijoined
20:09:13  * daviddiasquit (Quit: Textual IRC Client: www.textualapp.com)
20:11:25  * dignifiedquirequit (Quit: dignifiedquire)
20:13:42  * daviddiasjoined
20:15:21  * dignifiedquirejoined
20:18:04  * daviddiasquit (Client Quit)
20:18:25  * daviddiasjoined
20:19:14  * euoiajoined
20:19:51  * andrehjrquit (Quit: Computer has gone to sleep.)
20:23:58  * euoiaquit (Ping timeout: 240 seconds)
20:32:24  * andrehjrjoined
20:35:31  * euoiajoined
20:37:20  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:39:13  * daviddiasjoined
20:50:01  * dignifiedquirequit (Quit: dignifiedquire)
20:59:23  * a_lequit (Remote host closed the connection)
21:00:01  * a_lejoined
21:00:02  * kenperkinsjoined
21:00:52  * sh1mmer_joined
21:04:11  * sh1mmerquit (Ping timeout: 264 seconds)
21:11:22  * avalanche123quit (Remote host closed the connection)
21:11:59  * avalanche123joined
21:16:03  <chrisdickinson>tjfontaine: follow-up question, re: turning net.Server into a readable stream of sockets -- is the intention to leave the sockets in the kernel queue until there's a _read on the server?
21:19:02  * andrehjrquit (Quit: Computer has gone to sleep.)
21:27:01  <rendar>chrisdickinson: readable stream of sockets? what you mena?
21:27:03  <rendar>mean*
21:28:46  <chrisdickinson>the idea is to move accepting/rejecting sockets into JS; it would take the existing net.Server implementation and separate it into an objectMode readable stream piped to an objectMode writable.
21:28:47  <chrisdickinson>the objects, in this case, are net.Socket instances
21:39:13  * seishunquit (Ping timeout: 256 seconds)
21:46:19  * sh1mmer_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:47:42  * andrehjrjoined
21:49:34  <rendar>chrisdickinson: i see
21:49:48  <rendar>chrisdickinson: i thought node could already accept/reject sockets from js
21:50:34  <chrisdickinson>you can reject, but you can't leave a socket in the kernel queue
21:50:43  <chrisdickinson>(as i understand it.)
21:51:38  * janjongboomquit (Read error: Connection reset by peer)
21:52:14  * janjongboomjoined
21:54:29  <rendar>chrisdickinson: leaving a socket in the kernel queue? what you mean? if you reject a socket, it will be closed, otherwise it will be used..
21:56:12  <txdv>there is no way to reject sockets when you are listening
21:56:17  <txdv>you can accept them and close them
21:56:44  <txdv>there is no way in linux to do that either way, you have to get at least the fd, which you only get with a fd
21:56:45  <rendar>yeah, what txvd said
21:57:00  <rendar>because you get the socket address only after calling accept()
21:57:00  * janjongboomquit (Client Quit)
21:57:19  <rendar>then, based on the address you can reject sockets, e.g. rejects all sockets coming from 192.168.*
21:57:44  <rendar>if you want to reject in the kernel, you must use a firewall
21:58:16  * sh1mmerjoined
21:58:19  <chrisdickinson>that's why I'm trying to clarify the feature I'm working on with TJ
21:58:37  <rendar>chrisdickinson: how its supposed to work?
21:58:43  <chrisdickinson>well, yes, that :)
21:58:52  <rendar>:)
21:59:01  <rendar>are you working on a firewall?
21:59:18  <chrisdickinson>this is a feature TJ and I discussed at nodeconf that I said I would take a stab at
21:59:58  * euoiaquit (Ping timeout: 240 seconds)
22:00:00  <rendar>chrisdickinson: at that point isn't more convenient make node call directly the system firewall apis/shell-commands?
22:00:17  <chrisdickinson>it had started to seem to me like the goal was that Server._read would accept() up to hwm sockets at once
22:00:47  <chrisdickinson>& they'd otherwise wait in the kernel queue
22:00:57  <txdv>hwm?
22:00:58  <rendar>oh
22:01:01  <chrisdickinson>highwatermark
22:01:04  <rendar>i see
22:01:38  <rendar>chrisdickinson: you mean when Server._read is called, it will in turn call accept() which gives you only 1 socket to process, whilst the others are waiting their turn
22:04:42  <tjfontaine>chrisdickinson: ya, the socket stays in the kernel backlog until someone calls read, this allows for node processes in shared fd mode to accept when they want
22:05:24  <tjfontaine>rendar: the intent is that a server socket is akin to a readable socket, where a 'listening' event is akin to 'readable', and accept() is akin to read()
22:05:27  <chrisdickinson>the operating assumption I had up until about an hour ago, when I realized that libuv calls `accept` for you before connection_cb, was that JS would _read hwm sockets -- thus `accept`ing them, until the writable side of the server implementation filled up, at which point the kernel would start building up 0-backlog pending sockets
22:06:20  <rendar>tjfontaine: sockets stay in the kernel until someone calls accept(), not read() -- right?
22:06:25  * c4miloquit (Remote host closed the connection)
22:06:55  <rendar>tjfontaine: oh i see, you mean the js read() and not the C read(2) :-)
22:07:06  <tjfontaine>rendar: ya, I'm drawing an analog
22:07:25  <rendar>tjfontaine: that's interesting, the server fd has always be not utilized for i/o
22:07:35  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:07:49  <rendar>i always wondered "what happen if i read/write to it?" but never tried :)
22:07:52  <tjfontaine>rendar: well there's no way to apply backpressure currently to accept() in node.js
22:08:00  <tjfontaine>right htis is decidedly not that :)
22:08:05  <rendar>backpressure?
22:08:14  <tjfontaine>rendar: node is busy, and shouldn't accept a new connection
22:08:23  <rendar>oh
22:08:43  <chrisdickinson>tjfontaine: so does this involve adding machinery to libuv to prevent automatic `accept` of new sockets?
22:08:48  <tjfontaine>chrisdickinson: so connection_cb can fire 'readable' like event, right? the question is will it fire again if someone else shows up in the backlog
22:08:53  <tjfontaine>chrisdickinson: nope
22:09:29  <chrisdickinson>(I'm looking at https://github.com/joyent/libuv/blob/master/src/unix/stream.c#L468 + https://github.com/joyent/libuv/blob/master/src/unix/core.c#L406, specifically)
22:09:33  * paulfryzelquit (Ping timeout: 240 seconds)
22:09:38  * trevnorrisquit (Ping timeout: 240 seconds)
22:09:59  * brycebarilquit (Ping timeout: 272 seconds)
22:09:59  * julianduquequit (Ping timeout: 272 seconds)
22:10:02  * euoiajoined
22:10:09  <chrisdickinson>by the time connection_cb happens, the socket has been accept'd, it looks like
22:10:11  * AvianFluquit (Ping timeout: 264 seconds)
22:10:14  * Soarezchanged nick to Soarez|afk
22:10:53  * kenperkinsquit (Quit: Computer has gone to sleep.)
22:11:01  <rendar>tjfontaine: what about windows? can this be portable? for example in windows with named pipes you don't get 1 server fd, instead you create a new server fd for each incoming named pipe connection, this won't be true in unix domain sockets which work like network sockets
22:11:18  <tjfontaine>rendar: hand wave over windows for now :)
22:11:27  <rendar>lol
22:11:29  <rendar>:)
22:11:51  * trevnorrisjoined
22:11:54  * paulfryzeljoined
22:12:00  <rendar>tjfontaine: btw i think its a very interesting concept, it's worth try to go with further tries
22:12:15  <tjfontaine>chrisdickinson: I'm looking into this, technically what happens is that connection_cb should fire and then you uv_accept
22:12:27  <tjfontaine>chrisdickinson: I'm looking at the interaction of io_watcher and uv__accept
22:14:12  * AvianFlujoined
22:14:50  <chrisdickinson>hm. to clarify: is that "this should happen but isn't happening" or "chris has misunderstood the order of calls"?
22:14:53  <tjfontaine>chrisdickinson: bah, my fault I didn't realize it got broken up like that
22:15:34  * brycebariljoined
22:16:29  * julianduquejoined
22:17:22  <tjfontaine>chrisdickinson: yes, ok this will require a libuv change
22:18:26  <chrisdickinson>ah, cool -- that makes sense. I assume this is the sort of thing that we'll have to do in a backwards-compatible fashion (i.e., introduce a different, pre-connection_cb callback)?
22:19:12  <tjfontaine>chrisdickinson: libuv at least for now doesn't have the same concerns about backwards compat
22:19:50  <chrisdickinson>ah, cool
22:19:55  <tjfontaine>chrisdickinson: but you should sign up for the libuv mailing list to talk to saghul and indutny about this
22:19:58  <tjfontaine>:)
22:20:02  <tjfontaine>and me and LeftWing
22:20:09  <tjfontaine>:)
22:20:17  * rendarquit
22:20:36  <indutny>tjfontaine: could someone please post TLDR? :)
22:21:10  <tjfontaine>indutny: uv__server_io should not immediately call accept() but instead let uv_accept actually do that part
22:21:20  <indutny>heh
22:21:26  <indutny>ok, that's what I thought
22:21:29  <indutny>so
22:21:30  <tjfontaine>more or less
22:21:37  <indutny>there is some trickery
22:21:38  <indutny>with EMFILE
22:21:50  <indutny>I'm quite sure that this behavior is there for a reason
22:21:53  <chrisdickinson>ah, i saw that -- the extra fd for emergency purposes?
22:22:01  <indutny>yeah
22:22:06  <indutny>I'm not sure if it is still relevant
22:22:27  <indutny>perhaps saghul have something to share?
22:22:29  <indutny>chrisdickinson: anyway
22:22:33  <indutny>I'd go for a libuv@ email
22:22:38  <indutny>perhaps Ben will some something about it
22:22:44  <indutny>he is the author of that part anyway
22:22:52  <chrisdickinson>cool, thanks for the pointers!
22:23:55  <indutny>np
22:23:57  <indutny>you are welcome
22:24:12  <tjfontaine>indutny: it really doesn't need to be there (the emfile hack) if uv_accept itself could actually return that :)
22:24:24  <indutny>yes
22:24:32  <indutny>I agree
22:24:36  <tjfontaine>coolio
22:24:43  <indutny>but we should still let others know about it
22:24:49  <indutny>it would be great to hear Ben's feedback
22:24:57  <tjfontaine>tis why I suggested the mailing list :)
22:25:08  <indutny>yep
22:25:15  <indutny>oh
22:25:15  <indutny>btw
22:25:18  <indutny>since you are here
22:25:33  <indutny>mind taking a look at https://github.com/joyent/node/pull/7982 ?
22:25:45  <indutny>I'd like to backport some portions of it to v0.10 too
22:25:56  <indutny>especially NameDictionaryShape
22:26:00  <indutny>and
22:26:02  <indutny>Oddball thing
22:26:44  <tjfontaine>looks like indutny is doing lldb work :)
22:26:59  <indutny>em?
22:27:20  <tjfontaine>adding the postmortem work so you can inspect in lldb on osx?
22:28:53  <indutny>haha
22:28:54  <indutny>not really
22:30:04  <indutny>:)
22:30:10  <indutny>I'll show you that thing eventually
22:30:58  <tjfontaine>dap_1: hey can you take a look at https://github.com/joyent/node/pull/7982/files
22:31:27  <indutny>dap_1: please note that it won't fix mdb_v8 for now
22:31:35  <indutny>I'm just exposing the stuff that it is using
22:31:36  <dap_1>what's wrong with mdb_v8?
22:31:41  <tjfontaine>we would have to add the symbols
22:31:46  <indutny>dap_1: I don't think it will work with v0.11
22:31:54  <indutny>well
22:31:55  <indutny>it may be
22:32:00  <indutny>but the most of the symbols are gone
22:32:01  <tjfontaine>mdb_v8 is version independent really
22:32:03  <indutny>it is just using defaults
22:32:29  <nathan7>hey humans
22:32:40  <nathan7>I was trying to build myself a node with the latest V8
22:33:04  <nathan7>but it starts looking for includes in deps/v8 instead of deps/v8/include for some reason
22:33:26  <tjfontaine>they probably changed their gyp
22:34:55  <chrisdickinson>sent the proposed change to the libuv mailing list (it's pending approval) -- hopefully i did the situation justice :)
22:35:26  <indutny>chrisdickinson: approve
22:35:28  <indutny>approved*
22:35:29  <indutny>and replied
22:35:34  <indutny>I just did remember the one thing
22:35:37  <indutny>posted it on email
22:36:50  <nathan7>tjfontaine: mhm
22:37:11  <nathan7>so just dig around in the gyp files?
22:40:02  <chrisdickinson>ah, I've actually already moved the uv_accept out of the connection_cb -- https://github.com/chrisdickinson/node/compare/feature/net-stream#diff-e0caefcfacdafe13b6c0c402ae96f60fR186
22:40:06  <chrisdickinson>(apologies for the WIP-y code)
22:41:15  <chrisdickinson>if we're not picky about where the socket's are queued, then it might be okay to leave 'em in libuv?
22:47:30  * Soarez|afkchanged nick to Soarez
22:49:38  * euoiaquit (Ping timeout: 240 seconds)
22:53:38  * Soarezchanged nick to Soarez|afk
22:56:17  * benglquit (Ping timeout: 256 seconds)
22:58:50  * dshaw_joined
23:01:48  * c4milojoined
23:06:13  * c4miloquit (Ping timeout: 240 seconds)
23:06:45  * euoiajoined
23:07:48  * bengljoined
23:08:53  * sh1mmerquit (Quit: Textual IRC Client: www.textualapp.com)
23:09:23  * sh1mmerjoined
23:10:50  <nathan7>gen/debug-support.cc:6:16: fatal error: v8.h: No such file or directory #include "v8.h"
23:10:59  <nathan7>That's the thing I'm running into
23:11:38  <nathan7>ah
23:11:47  <nathan7>everything seems to do #include <include/v8.h> now
23:13:49  <nathan7>ah, now a zillion other things break
23:13:58  * euoiaquit (Ping timeout: 240 seconds)
23:15:42  * inolenquit (Quit: Leaving.)
23:20:30  * euoiajoined
23:20:51  * AvianFluquit (Remote host closed the connection)
23:21:39  * c4milojoined
23:35:45  * dsantiagoquit (Read error: Connection reset by peer)
23:36:01  * dsantiag_joined
23:37:56  * dsantiag_quit (Read error: Connection reset by peer)
23:38:14  * dsantiagojoined
23:47:48  * avalanche123quit (Remote host closed the connection)
23:48:21  * avalanche123joined
23:49:21  * a_lequit (Read error: Connection reset by peer)
23:49:56  * avalanche123quit (Remote host closed the connection)
23:50:08  * avalanche123joined
23:51:23  * c4miloquit (Remote host closed the connection)
23:59:12  * dsantiagoquit (Read error: Connection reset by peer)
23:59:51  * dsantiagojoined