00:00:06  <TooTallNate>LOUD NOISES!!
00:00:07  <indutny>so it's very unlikely (but still possible) introducing bugs
00:00:17  <indutny>TooTallNate: you're really tall, btw :P
00:00:20  * piscisaureus_quit (Ping timeout: 264 seconds)
00:00:28  <TooTallNate>indutny: haha, it's true :p
00:00:49  <TooTallNate>indutny: i did see one or two people taller then me at the conf though, it was a little strange, haha
00:01:22  <indutny>hahah
00:01:26  <indutny>looking upwards?
00:01:54  <isaacs>node appeals to very tall men.
00:01:56  <isaacs>not sure why
00:02:00  <indutny>hahahaha
00:02:20  <isaacs>mjr, creationix, tootallnate, felix, etc
00:02:23  <isaacs>evne ry's pretty tall.
00:02:59  <isaacs>and he's like one of the shorter node people. that's why i hang out with mikeal so much, he's the only one who doesn't make me feel tiny.
00:04:41  <indutny>btw, is ryan living in SF too?
00:04:44  <indutny>i mean CA
00:08:20  <indutny>isaacs: %
00:08:22  <indutny>isaacs: ^
00:09:01  <isaacs>yeah, he lives in SF
00:09:06  <isaacs>in the West Bay
00:09:13  <isaacs>i'm in The City (aka oakland)
00:10:51  * rendarquit
00:25:22  * EhevuTovquit (Quit: Leaving)
00:26:03  <CIA-108>node: Tim Macfarlane v0.8 * r0dba28b / lib/readline.js : readline: fix for unicode prompts - http://git.io/io9YOA
00:27:33  <indutny>yeah, I know oakland
00:27:37  <indutny>jchris lives here too
00:27:46  <indutny>or lived here, don't really know how he's doing now
00:35:41  <indutny>bnoordhuis: I've explained that ;)
00:37:03  <indutny>bnoordhuis: so are we going to allow session reusal between cluster processes?
00:41:47  * bcantrillquit (Quit: Leaving.)
00:42:32  * c4miloquit (Remote host closed the connection)
00:53:40  <bnoordhuis>indutny: session reusal?
00:53:49  <bnoordhuis>you mean ssl session reuse?
00:54:05  <indutny>bnoordhuis: yes
00:54:52  <bnoordhuis>indutny: i think that only works when you have shared memory and cross-process mutexes, right?
00:56:59  <indutny>right
00:57:34  <indutny>do we need some special mutexes handling uv for unixes?
00:57:37  <bnoordhuis>well, that's a problem - libuv supports neither shm or PTHREAD_PROCESS_SHARED mutexes
00:57:48  <indutny>ah
00:57:56  <indutny>shm is kind of retarded, AFAIK
00:58:01  <bnoordhuis>yeah
00:58:18  <bnoordhuis>but libuv neither supports cross-fork mmap :)
00:58:29  <indutny>indeed
00:58:35  <indutny>it doesn't have mmap support at all
00:58:40  <bnoordhuis>exactly :)
00:58:48  <indutny>but it can have it
00:58:59  <indutny>I'm quite sure that windows has shared memory support
00:59:07  <bnoordhuis>it has
00:59:15  <bnoordhuis> PTHREAD_PROCESS_SHARED is kind of problematic though
00:59:21  <indutny>what's really interesting is that we'll need to extend uv_spawn API
00:59:40  <indutny>how would that work on windows?
01:00:41  <bnoordhuis>with normal mutexes
01:01:25  <indutny>doesn't it have shared mutexes?
01:01:33  <indutny>what's the point of shared memory without mutexes?
01:01:43  <indutny>you can't do anything with it at all
01:01:49  <bnoordhuis>heh
01:02:06  <bnoordhuis>"normal" a.k.a. heavy-weight mutexes are the windows equivalent of PTHREAD_PROCESS_SHARED
01:02:19  <bnoordhuis>it's CriticalSection mutexes that you can't share
01:03:25  <indutny>well, we're using CriticalSections anyway, as I know
01:03:48  <indutny>ok, we just should off-load that to bertje
01:04:06  <indutny>we need to implement support for that in uv, anyway
01:04:17  <indutny>and then after benchmarking we'll disable it on windows in node
01:05:32  <indutny>so, I propose adding uv_shmutex_t
01:05:39  <indutny>and uv_shmutex_*()
01:07:27  * ericktquit (Ping timeout: 252 seconds)
01:07:58  <bnoordhuis>indutny: the reason i said it's problematic is that not all unices have shared mutexes
01:08:06  <indutny>oh my zosh
01:09:04  <bnoordhuis>linux does, i'm pretty solaris does too, freebsd's implementation used to have bugs
01:09:22  <bnoordhuis>which means os x's implementation probably has or had bugs as well
01:10:02  <indutny>ok, that's really nice
01:10:19  <indutny>we can try using lock-less structures, but the overhead will be really big
01:10:28  <indutny>and probably bigger than benefits from shared session storage
01:10:45  <bnoordhuis>yes. let's punt on this for a bit
01:11:41  <indutny>deal
01:12:03  <bnoordhuis>indutny: which is not to say you can't hack on a quick prototype
01:12:14  <indutny>bnoordhuis: well, I wasn't saying that I won't do anything :P
01:12:19  <bnoordhuis>heh, okay
01:12:34  <indutny>http://fscked.org/writings/SHM/shm-3.html
01:12:36  <indutny>really nice ^
01:13:03  <bnoordhuis>haha
01:13:51  <bnoordhuis>indutny: i would generally recommend to use shared mmap'd memory
01:13:59  <bnoordhuis>much easier than sysv or posix shm
01:14:02  <indutny>indeed
01:14:26  <indutny>well, all I need is just passing pointer to the forks, right?
01:14:39  <indutny>they should already have COW memory of parent process
01:16:05  <bnoordhuis>indutny: explain 'passing pointer'?
01:16:14  <indutny>well, suppose I do
01:16:19  <bnoordhuis>the idea is to store the sessions themselves in shm
01:16:26  <indutny>void* ptr = mmap(...)
01:16:44  <indutny>if (!fork()) {
01:16:44  <indutny>}
01:16:46  <indutny>err
01:16:52  <indutny>if (!fork()) use(ptr);
01:16:57  <bnoordhuis>right, that works
01:17:08  <indutny>is there any other ways (except named regions)?
01:17:11  <bnoordhuis>provided you mmap'd it with MAP_SHARED of course :)
01:17:17  <indutny>yeah
01:17:19  <indutny>I understand that
01:17:42  <bnoordhuis>no, pointer passing works - the forks inherit the memory mappings
01:17:58  <indutny>ok, going to hack this out
01:18:04  <bnoordhuis>good luck :)
01:18:12  <indutny>I wonder if splay tree will handle enough of load
01:18:20  <indutny>err
01:18:27  <indutny>will do searches in reasonable time
01:18:43  <indutny>I really do not want a RB-tree here
01:18:50  <bnoordhuis>benchmark it and you'll know
01:19:01  <indutny>yeah
01:19:25  <bnoordhuis>though in my experience different data structures with similar big O behavior don't usually have wildly different performance characteristics
01:19:43  <indutny>well, RB has O(1) insertion
01:19:59  <indutny>splay has O(log n)
01:20:09  <indutny>oh
01:20:13  <bnoordhuis>a red/black tree is also O(log n) insertion
01:20:20  <bnoordhuis>you need to find the place to insert to first
01:20:23  <indutny>yeeah
01:20:30  <indutny>indeed, I forgot about that
01:20:48  <indutny>so the difference is only in worst cases here
01:21:14  <bnoordhuis>it's more that people always bitch and moan about the cache characteristics of binary trees vs. hashes and such
01:21:35  <indutny>hashes are good
01:21:36  <indutny>really good
01:21:42  <indutny>but they eat a lot of memory
01:21:44  <indutny>and hard to cleanup
01:27:14  * mmaleckijoined
01:28:41  * abraxasjoined
01:29:14  <indutny>actually, I love hashmaps
01:29:18  <indutny>:D
01:34:09  <bnoordhuis>i'm going to think hard and deep on how to deal with signals, threads and multiple event loops
01:34:33  <bnoordhuis>and i'm going to do it from the comfort of my own bed
01:34:37  <bnoordhuis>sleep tight people
01:35:10  <indutny>sleep tight ben
01:35:27  <bnoordhuis>you too, fedor
01:36:21  <mmalecki>night Ben
01:39:27  * bnoordhuisquit (Ping timeout: 240 seconds)
01:41:22  * mmaleckiquit (Ping timeout: 244 seconds)
02:18:57  <indutny>oh grammar is really borked in cluster.js
02:18:59  <indutny>wtf
02:19:12  <indutny>even I'm noticing this
02:28:23  * ericktjoined
02:49:41  * TooTallNatequit (Ping timeout: 255 seconds)
02:56:08  * brsonquit (Quit: leaving)
03:02:10  * mjr_joined
03:09:49  * perezdquit (Quit: perezd)
03:23:46  * mjr_quit (Quit: mjr_)
03:24:08  * mjr_joined
03:38:48  * brsonjoined
03:49:44  * mjr_quit (Quit: mjr_)
05:07:26  * bcantrilljoined
05:10:12  * perezdjoined
05:10:33  * isaacs_mobilejoined
05:30:06  * paddybyersjoined
05:48:40  * isaacs_mobilequit (Quit: Leaving)
06:08:43  * EhevuTovjoined
06:26:48  * isaacs_mobilejoined
06:30:37  * mmaleckijoined
06:35:48  * loladirojoined
06:37:18  * loladiroquit (Client Quit)
06:44:23  * hzjoined
06:46:37  * isaacs_mobilequit (Ping timeout: 252 seconds)
06:54:00  * stephankquit (Quit: *Poof!*)
07:01:29  * stephankjoined
07:08:25  * rendarjoined
07:27:56  * EhevuTovquit (Quit: Leaving)
07:38:23  * mmaleckiquit (Ping timeout: 265 seconds)
07:55:58  * AlbireoXchanged nick to AlbireoX`Away
07:56:01  * AlbireoX`Awaychanged nick to AlbireoX
08:09:10  * mmaleckijoined
08:26:00  * bcantrillquit (Quit: Leaving.)
08:53:04  * brsonquit (Remote host closed the connection)
10:21:31  * abraxasquit (Remote host closed the connection)
11:05:36  * mmaleckiquit (Quit: leaving)
12:05:52  * piscisaureus_joined
12:09:57  * bnoordhuisjoined
12:26:24  * loladirojoined
12:32:13  <piscisaureus_>bah
12:32:13  <piscisaureus_>INSTALL.W64: No assembler modules are engaged upon initial 0.9.8 release.
12:32:13  <piscisaureus_>INSTALL.W32: Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/ is required if you intend to utilize assembler modules. Note that NASM is now the only supported assembler.
12:36:44  * loladiro_joined
12:38:37  * loladiroquit (Ping timeout: 252 seconds)
12:38:37  * loladiro_changed nick to loladiro
12:43:07  <piscisaureus_>hmm the state of ssl is a mess...
12:43:23  <piscisaureus_>WARNING: mkdef.pl doesn't know the following algorithms:
12:43:23  <piscisaureus_> NEXTPROTONEG
12:43:36  <piscisaureus_>I presume that was added by the chromium guys>
12:50:45  * hzquit
12:54:43  * loladiroquit (Ping timeout: 246 seconds)
12:54:59  * loladirojoined
13:05:03  * loladiroquit (Ping timeout: 255 seconds)
13:30:29  * loladirojoined
13:38:34  * chobi_e_changed nick to chobi_e
13:42:58  <piscisaureus_>Hmm, ok, so for x64 only gcc is supported
13:43:00  <piscisaureus_>bleh
13:43:18  <piscisaureus_>manual porting action
13:56:43  <loladiro>piscisaureus_: Did you get to look at the IPC stuff yet?
14:10:20  <indutny>piscisaureus_: hey man
14:10:25  <indutny>bnoordhuis: oh hey
14:11:17  <indutny>bweaver: should I do something special, except adding MAP_ANON | MAP_SHARED flag to mmap to get it working between forks
14:13:53  <indutny>oops
14:13:59  <indutny>bweaver: sorry, wrong tab completion
14:15:34  * mmaleckijoined
14:18:11  <piscisaureus_>loladiro: not yet, sorry
14:18:20  <piscisaureus_>indutny: hey
14:18:31  <bnoordhuis>indutny: no, that's all you need
14:18:46  <indutny>bnoordhuis: odd, because I'm getting undefined values when accessing this memory from forks
14:18:49  <indutny>:(
14:19:03  <indutny>and I'm quite sure that I'm getting the same pointer as the parent has
14:19:41  <indutny>bnoordhuis: so basically the code here https://github.com/indutny/node/compare/feature-ssl-shared-cache#L9R639
14:19:43  <indutny>fails
14:20:02  <indutny>and that storage is created using this: https://github.com/indutny/node/compare/feature-ssl-shared-cache#L11R98
14:20:51  <indutny>btw, I think we may use semaphores as a shared mutexes on osx
14:22:46  <bnoordhuis>indutny: https://gist.github.com/40d9c0316c083f1366ac <- does that code work for you?
14:22:58  <bnoordhuis>i guess you'll have to adapt it a little for os x
14:23:07  <indutny>sec, let me try
14:23:15  <indutny>you mean adapt your code?
14:23:31  <bnoordhuis>indutny: yes. i doubt os x has clock_gettime() :)
14:27:25  * c4milojoined
14:27:43  <indutny>ok, it's failing in mq_init
14:27:45  <indutny>:)
14:28:05  <indutny>I don't think that osx has semaphores in this way
14:28:11  <indutny>it's using some Mach junk for them
14:28:26  <bnoordhuis>that might very well be the case
14:28:57  <indutny>well, but I'm not using semaphores in my code
14:29:35  <indutny>hm...
14:30:10  <indutny>yeah https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/synchronization/synchronization.html
14:30:22  <bnoordhuis>indutny: have you tried your code on linux? it's possible that os x doesn't support MAP_ANONYMOUS | MAP_SHARED
14:30:35  <indutny>it support MAP_ANON
14:30:54  <indutny>ah, so you think it's only supporting non-anonymous shared memory?
14:31:00  <bnoordhuis>possibly
14:31:10  <indutny>yeah, I can /dev/zero it, I suppose
14:31:11  <tjfontaine>udp should behave the same as tcp here right? https://gist.github.com/3060476
14:32:42  <bnoordhuis>tjfontaine: yes
14:33:59  <tjfontaine>alright I guess I'll do a pull req :)
14:34:20  <indutny>oh crap
14:34:23  <indutny>bnoordhuis: you were right
14:34:35  <indutny>bnoordhuis: it works with mmaped file
14:34:41  <indutny>or, no
14:34:42  <indutny>wtf
14:34:48  <indutny>it just suddenly crashed
14:35:26  <indutny>oh, great it was just slowly mmaping file and then failing
14:35:29  <indutny>really nice
14:36:00  <bnoordhuis>haha
14:36:10  <bnoordhuis>system programming is awesome, isn't it?
14:36:54  <indutny>yeah, indeed
14:37:03  <indutny>things are just like they're described in man
14:37:08  <indutny>nothing unexpected
14:38:24  <indutny>ok, I got ENODEV
14:39:23  <tjfontaine>bnoordhuis: should just the emit of listening be delayed to the nextTick or also the call to _startReceiving?
14:39:31  <indutny>oh crap
14:39:34  <indutny>I added MAP_ANON
14:39:42  <indutny>and it's returning EACCES
14:39:49  <indutny>bnoordhuis: int fd = open("/dev/zero", O_RDWR);
14:39:55  <indutny>am I doing something wrong?
14:40:02  <mmalecki>anyone up for reviewing https://github.com/joyent/node/pull/3635 ?
14:40:12  <indutny>I suppose this file should be open for both read and write, isn't it?
14:40:18  <piscisaureus_>indutny: I suppose you can't mmap /dev/zero
14:40:24  <piscisaureus_>that would be insanity anyway
14:40:40  <indutny>really insane
14:40:41  <bnoordhuis>tjfontaine: both
14:40:59  <indutny>mmalecki: how much performance improvement does it make?
14:41:06  <tjfontaine>bnoordhuis: ok
14:41:12  <indutny>mmalecki: I've looked at this stuff some time ago
14:41:21  <indutny>mmalecki: and there was no visible performance improvement here
14:42:00  <bnoordhuis>indutny, piscisaureus_: it should be possible to mmap /dev/zero, i've seen it used as a trick to quickly zero big slabs of memory
14:42:05  <indutny>piscisaureus_: well /tmp/1 can't be used too :)
14:42:26  <mmalecki>indutny: I can post some gist with siege output, but there wasn't some *big* performance impact
14:42:34  <mmalecki>like 5 ms/1000 reqs or so?
14:42:56  <indutny>mmalecki: well, it may be a statistical deviation
14:43:15  <indutny>mmalecki: read is doing call to C++ land which costs much more than running non-optimized function
14:43:29  <indutny>and optimization/deoptimization takes some extra time
14:43:47  <mmalecki>indutny: wait, which thing are we talking about?
14:43:50  <mmalecki>fs.read or http thing?
14:43:53  <indutny>so as this function is not really hot, I propose waiting for v8 guys to make it work
14:44:05  <indutny>fs.read
14:44:13  <mmalecki>oh, no, I linked https://github.com/joyent/node/pull/3635
14:44:28  <mmalecki>indutny: I didn't measure fs.read performance, I just noticed that it bails out and fixed it
14:44:43  <indutny>mmalecki: ok, bailout basically means that they haven't implemented this feature yet
14:44:56  <mmalecki>right
14:44:59  <indutny>#elif (NGX_HAVE_MAP_DEVZERO)
14:45:09  <mmalecki>but that's how we always parse arguments anyway, right?
14:45:11  <indutny>bnoordhuis: I suppose nginx has special configure test for that stuff
14:45:22  <mmalecki>you don't usually use arguments[i] when you have named arguments anyway
14:47:12  <indutny>bnoordhuis: well, actually I think that it should fail or work
14:47:21  <indutny>I can't see any description of this problem on the internet
14:48:14  <mmalecki>but anyway, what I was asking about is https://github.com/joyent/node/pull/3635
14:48:29  <mmalecki>bnoordhuis: you might be interested ^
14:48:48  <indutny>removing a lot of code
14:48:49  <indutny>good :)
14:49:23  <mmalecki>"26 additions and 64 deletions" makes me a happy panda too :)
14:50:51  * creationixjoined
14:51:03  * creationixpart
14:51:07  * creationixjoined
14:52:37  <indutny>bnoordhuis: master: 0x102200000 size: 10240
14:52:37  <indutny>0x102200000
14:52:37  <indutny>Assertion failed: (st->is_shared()), function UseSharedSessionStorage, file ../src/node_crypto.cc, line 640.
14:52:40  <indutny>oohh crap
14:56:16  <indutny>bnoordhuis: ok, the problem is in my code
14:56:20  <indutny>https://gist.github.com/4083bddd75c2078c1efc <- this is working
14:56:30  <indutny>bbiab need to eat some sushi :)
14:59:06  * ericktquit (Quit: erickt)
15:00:35  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:00:46  <bnoordhuis>company meeting, back in an hour (hopefully)
15:01:11  <mmalecki>lol, company meeting which lasts an hour?
15:15:50  * piscisaureus_joined
15:17:09  * hzjoined
15:37:03  * ericktjoined
15:38:28  * chobi_echanged nick to chobi_e_
15:39:39  * theColejoined
15:40:03  <bnoordhuis>mmalecki: there's beer involved
15:41:12  <tjfontaine>bnoordhuis: so deferring startReceiving breaks implicit bind on send semantics, and this all has to do with the fact that dgram lookup is synchronous for .bind where address is undefined or an ip
15:41:24  <mmalecki>bnoordhuis: well, at *our* standups, there's vodka involved
15:41:28  <mmalecki>if you bring one, of course
15:41:45  <mmalecki>bnoordhuis: also, did you see that http thing?
15:41:46  <tjfontaine>there's a "in soviet russia" joke there somewhere
15:42:56  * piscisaureus_quit (Ping timeout: 264 seconds)
15:47:04  * mmaleckiquit (Quit: leaving)
15:54:52  <tjfontaine>dear internets, please dont' cut out whilst I'm running `make test` it's depressing
15:55:06  * perezdquit (Quit: perezd)
16:04:11  <bnoordhuis>tjfontaine: exec screen :)
16:04:51  <bnoordhuis>tjfontaine: re bind on send, yes, that's a problem
16:06:19  <tjfontaine>bnoordhuis: oh of course I'm in screen, just always freaks me out :) also, I'm going to finish this pullreq and let you decide the way forward
16:06:24  * loladiroquit (Quit: loladiro)
16:07:58  * loladirojoined
16:09:51  <tjfontaine>bnoordhuis: https://github.com/joyent/node/pull/3655
16:10:58  * AlbireoXquit (Ping timeout: 245 seconds)
16:12:13  * loladiroquit (Ping timeout: 245 seconds)
16:15:26  <isaacs>So, I'm thinking I'm going to try to make Friday Build Day.
16:15:51  <isaacs>release unstable, start stable, and we can release stable on monday or tuesday, after banging on it a little bit.
16:19:17  <creationix>isaacs, how automated is all the packaging and release stuff?
16:19:37  * perezdjoined
16:19:40  <isaacs>creationix: well, it's pretty automated if you count muscle memory
16:19:53  <creationix>nice
16:19:53  <isaacs>creationix: and i try to root cause all the mistakes i make and fix them
16:20:07  <isaacs>but robot helpers would be nice
16:20:12  <creationix>luvit releases take me way too long
16:20:16  <isaacs>or human helpers :)
16:20:20  <creationix>that's why there aren't very many
16:20:38  <creationix>yeah, rphillips usually does the windows build for me
16:21:46  <rphillips>somebody is working on an installer for our product... I should be able to port it to luvit eventually
16:24:59  <creationix>rphillips, nice
16:27:28  * dapjoined
16:29:31  * bnoordhuisquit (Ping timeout: 244 seconds)
16:52:10  * AndreasMadsenjoined
16:53:58  * theColequit (Quit: theCole)
17:09:21  * AlbireoX_joined
17:14:19  * TooTallNatejoined
17:20:35  * loladirojoined
17:26:21  * brsonjoined
17:27:31  <indutny>oh man
17:34:41  <indutny>isaacs: hey man
17:34:56  * theColejoined
17:34:59  <indutny>a question about concepts and the part of eternal one "To be or not to be... in core"
17:35:39  <indutny>so, I just realized that's impossible (or at least I do not know how to make it possible) to make node have shared session storage between forks
17:36:21  <indutny>that's because they can't have shared memory (execve and others are detaching shared memory from parent process)
17:37:23  <indutny>but, to my mind, it is the feature that can/should be in the core. The possible solution would parsing ClientHello TLS frame, which is unencrypted and comes first (so should be quite straightforward to parse in C++)
17:38:50  <indutny>isaacs: and this way we may allow users to choose any external storage they like (i.e., redis, mongodb or even mysql)
17:39:01  <indutny>because it'll work asynchronously
17:39:49  <isaacs>indutny: the typical way of doing this is that users just have a config file or something, and put there stuff wherever.
17:40:09  <indutny>isaacs: what do you mean?
17:40:11  <isaacs>indutny: i do shared session storage between forked children in a cluster. it's not too hard.
17:40:15  <isaacs>you just set a cookie.
17:40:26  <isaacs>or are you talking about TLS session?
17:40:26  <indutny>isaacs: ah, we're talking about different session storages
17:40:29  <indutny>isaacs: yes
17:40:30  <isaacs>heh
17:40:37  <isaacs>gotcha. yeah, that's a trickier animal.
17:40:53  <indutny>isaacs: indeed, but we may do it in core just to make tls faster
17:40:58  <isaacs>right
17:41:01  <indutny>isaacs: or I may do it in user-land
17:41:07  <indutny>that's the question :)
17:41:15  <isaacs>indutny: i'd say, do it in userland first, and see what's missing in core to enable that.
17:41:28  <isaacs>my typical answr to this sort of question, btw ^
17:41:39  <indutny>well, nothing is needed in core for that
17:41:40  <indutny>:D
17:41:42  <indutny>really
17:41:55  <isaacs>i mean, do it in a userland pure-js module.
17:42:01  <isaacs>i see C++ addons as admissions of failure.
17:42:06  <indutny>yeah, that's it
17:42:13  <isaacs>sometimes they're reasonable failures, you can't win everything.
17:42:17  <indutny>ok, I'll come to you with it later
17:42:30  <isaacs>but it's dumb to tell 99% of users that they need some C++ thing. in that case, it should just be in core.
17:42:38  <isaacs>C++ addons should be rare exceptions.
17:42:39  <kohai>C has 18 beers
17:42:49  <AvianFlu>man, that's my favorite kohai bug ever
17:43:09  <isaacs>:D
17:43:13  <isaacs>C--
17:43:13  <kohai>C has 17 beers
17:43:37  <indutny>isaacs: well, the thing is that session resumption won't work without that user-land module
17:43:48  <indutny>isaacs: I mean resumption in cluster, of course
17:43:58  <isaacs>indutny: so, it sounds like, there'd be some async way to have the TLS session associate with a key
17:44:05  <indutny>yes
17:44:15  <isaacs>and then you give the thing a function that gets some blob of data, and stores it wth that key
17:44:25  <isaacs>or gets a key and returns the blob of data
17:44:31  <indutny>exactly
17:44:43  <isaacs>and then it's up to you to do redis, or fs, or sql, or shmop, or whatever.
17:44:59  <indutny>yes, just fire callback once you finished
17:45:00  <isaacs>maybe even just process.send() to the master and have it store in memory
17:45:08  <indutny>indeed
17:45:09  <isaacs>how much data are we talking about?
17:45:24  <indutny>well, it's about 1-2kbs per sesion
17:45:28  <indutny>s/sesion/session
17:45:50  <isaacs>so, if you have 1000 concurrent users, it's like 1MB flying around, per request?
17:46:03  <isaacs>or, no, since they reuse the socket
17:46:09  <isaacs>it's just establishing the connection, right?
17:46:44  <isaacs>that sounds really reasonable to do with redis, and not out of the question to do with fs or IPC, though they'd probably be kinda slow
17:46:52  * loladiroquit (Ping timeout: 255 seconds)
17:47:06  <indutny>isaacs: yes
17:47:24  <indutny>isaacs: actually, I think we should try following way
17:47:31  <indutny>isaacs: implement it as user-land module
17:47:38  <indutny>and see how many people will really use it
17:47:52  <indutny>then, eventually, lift it to core (if needed)
17:48:21  <isaacs>sure
17:48:29  <isaacs>i suspect this'll just be something we end up pulling into 0.9
17:48:40  <isaacs>it doesn't sound like a huge API, and it's possible to do without breaking anything.
17:49:31  * loladirojoined
17:49:35  <indutny>indeed
17:50:22  <isaacs>server.on('sessionSave', function (key, val, cb) { ... }); server.on('sessionResume', function (key, cb) { ... })
17:50:27  <isaacs>then we can do something like":
17:50:51  <isaacs>if (server.emit('sessionSave', key, val, next)) { // expect next() to be called later, otherwise don't }
17:53:13  <isaacs>since emit() returns true if a listener was called
17:54:53  * isaacscommuting
17:54:55  <indutny>yes, I've one such module
17:54:57  <indutny>but it's private
17:55:14  <indutny>though I don't think there're any reason for it to not be opensource, anymore
17:55:20  <isaacs>indutny: just go ahead and do it in core. everyone needs this, and most people don't know they need it.
17:55:28  <indutny>ah
17:55:32  <indutny>hahaha
17:55:35  <indutny>kk
17:55:36  <isaacs>i mean, emit the method, and use the results.
17:55:42  <isaacs>but on master, this is above v0.8
17:55:56  <indutny>yes, that's the API I thought about
17:56:03  <isaacs>kewl :)
17:56:13  <isaacs>that's always a good sign when we agree before discussing it :)
17:56:20  <indutny>hehe
17:56:22  <indutny>yeah
17:56:24  <isaacs>ok, gotta run
17:56:26  <isaacs>thanks!
17:56:31  <indutny>isaacs: thank you
17:56:32  <indutny>see ya
18:05:23  * loladiroquit (Quit: loladiro)
18:33:32  * EhevuTovjoined
18:54:48  <tjfontaine>sigh, I'm going further down the rabbit hole, into territory that's going to break behavior and more than likely not end up being fixed for 0.8
18:55:10  * mjr_joined
18:56:06  * hzquit
18:58:37  * `3rdEdenjoined
19:10:32  <TooTallNate>we should probably merge this unless there's any objections: https://github.com/joyent/node/pull/3580
19:18:59  * loladirojoined
20:00:10  * loladiroquit (Quit: loladiro)
20:07:07  * `3rdEdenquit (Quit: Leaving...)
20:26:48  * loladirojoined
20:30:45  * loladiro_joined
20:33:20  * loladiroquit (Ping timeout: 264 seconds)
20:33:20  * loladiro_changed nick to loladiro
20:34:46  * loladiroquit (Read error: Connection reset by peer)
20:34:51  * loladiro_joined
20:35:15  * loladiro_changed nick to loladiro
20:41:53  <isaacs>TooTallNate: lgtm
20:42:00  <isaacs>merge at will, but squash please
20:42:12  <TooTallNate>isaacs: ok will do
20:42:26  <isaacs>x
20:42:27  <isaacs>tnx
20:44:37  <tjfontaine>isaacs: do you have an opinion on if such a change would make it into 0.8? https://github.com/joyent/node/pull/3655#issuecomment-6813775 .bind is only synchronous when called without a hostname (or if the hostname is an ip)
20:45:21  * c4miloquit (Remote host closed the connection)
20:55:28  * AndreasMadsenquit (Remote host closed the connection)
21:05:32  <TooTallNate>isaacs: same with this module .json patch, master or v0.8?
21:18:53  * loladiroquit (Ping timeout: 245 seconds)
21:37:01  * brsonquit (Remote host closed the connection)
21:38:22  * brsonjoined
21:53:51  <isaacs>TooTallNate: the module .json filename patch we can land in 0.8
21:54:04  <isaacs>the udp bind thing is a bit more dicy
21:54:14  <isaacs>it *does* need to be alwasy-sync or always-async
21:54:19  <isaacs>(that's what process.nexttick is for)
21:54:31  <isaacs>and the tests should assume async-ness, not sync-ness
21:56:43  * rendarquit
21:59:16  * piscisaureus_joined
22:10:12  * loladirojoined
22:11:37  * brsonquit (Quit: leaving)
22:29:01  <CIA-108>node: TJ Holowaychuk v0.8 * red7fb14 / (3 files in 3 dirs): module: add filename to require() json errors - http://git.io/GOuBQw
22:29:34  <isaacs>thanks
22:31:13  * chobi_e_changed nick to chobi_e
22:37:13  <tjfontaine>ya, I think people should be assuming it works asyncly, but I don't know how many are using the way it accidentally worked
22:37:57  * chobi_echanged nick to chobi_e_
22:49:20  <isaacs>man, nothing but npm cleanup and fixing today
22:56:18  * loladiroquit (Ping timeout: 246 seconds)
22:57:12  * brsonjoined
22:58:12  * loladirojoined
23:29:58  * bnoordhuisjoined
23:33:06  * loladiroquit (Read error: Connection reset by peer)
23:33:55  * loladirojoined
23:42:38  * loladiroquit (Read error: Connection reset by peer)
23:42:44  * loladiro_joined
23:44:34  * EhevuTovquit (Quit: Leaving)