00:00:43  * bnoordhuisquit (Ping timeout: 240 seconds)
00:06:17  * mralephquit (Quit: Leaving.)
00:21:33  <DrPizza>hmm
00:21:45  <DrPizza>ryah: do you know where I can find npn patches for openssl 1.0?
00:21:54  <DrPizza>it looks like npn will be integrated into 1.1
00:39:19  * piscisaureusquit (Read error: Operation timed out)
00:42:14  * piscisaureusjoined
02:37:39  * brsonquit (Ping timeout: 252 seconds)
04:17:11  * isaacsjoined
04:39:03  * piscisaureusquit (Ping timeout: 258 seconds)
05:23:42  * isaacsquit (Quit: isaacs)
06:05:07  * mralephjoined
06:54:40  * mralephquit (Quit: Leaving.)
11:04:54  * bnoordhuisjoined
13:02:08  * piscisaureusjoined
13:47:12  * _jnequit (Quit: leaving)
13:54:25  * ofcjoined
13:55:41  <bnoordhuis>udp_packet_storm_1v1: 119053/s received, 119053/s sent
13:55:42  <bnoordhuis>udp_packet_storm_10v1: 119843/s received, 119843/s sent
13:55:42  <bnoordhuis>udp_packet_storm_100v1: 119474/s received, 119475/s sent
13:55:42  <bnoordhuis>udp_packet_storm_1000v1: 118607/s received, 118607/s sent
13:55:42  <bnoordhuis>udp_packet_storm_10v10: 168740/s received, 168740/s sent
13:55:42  <bnoordhuis>udp_packet_storm_100v10: 167760/s received, 167762/s sent
13:55:44  <bnoordhuis>udp_packet_storm_1000v10: 167064/s received, 167064/s sent
13:55:46  <bnoordhuis>udp_packet_storm_100v100: 146019/s received, 146026/s sent
13:55:48  <bnoordhuis>udp_packet_storm_1000v100: 145513/s received, 145526/s sent
13:55:50  <bnoordhuis>udp_packet_storm_1000v1000: 124197/s received, 124256/s sent
13:55:52  <bnoordhuis>^ sunos, acceptable
13:56:06  <piscisaureus>better than linux
13:56:18  <bnoordhuis>it should be, seeing what machine it runs on
13:57:09  <bnoordhuis>but for example pipe performance is a joke
13:57:10  <bnoordhuis>pipe_pump1_server: 3.2 gbit/s
13:57:10  <bnoordhuis>pipe_pump1_client: 3.2 gbit/s
13:57:18  <piscisaureus>slow
13:57:23  <piscisaureus>even worse than windows
13:57:31  <bnoordhuis>yeah, it's ridiculous
14:03:02  <bnoordhuis>piscisaureus: maybe we should scrap UV_UDP_REUSEADDR
14:03:16  <bnoordhuis>it works differently across the unices
14:03:21  <piscisaureus>oh?
14:03:24  <piscisaureus>what's the difference?
14:03:25  <bnoordhuis>linux works okay
14:03:39  <bnoordhuis>bind_twice_v4 fails on darwin
14:03:43  <bnoordhuis>bind_twice_v3 fails on sunos
14:04:00  <bnoordhuis>haven't tested freebsd yet
14:04:50  <piscisaureus>bnoordhuis: I figured out that in theory windows might report udp send errors
14:04:58  <piscisaureus>but I never see it happen
14:05:29  <piscisaureus>WSARecvFrom:
14:05:30  <piscisaureus>WSAECONNRESET - The virtual circuit was reset by the remote side executing a hard or abortive close. The application should close the socket as it is no longer usable. For a UPD datagram socket, this error would indicate that a previous send operation resulted in an ICMP "Port Unreachable" message.
14:05:57  <bnoordhuis>piscisaureus: if it's anything like the unices, you have to explicitly read out the error queue
14:06:25  <bnoordhuis>i've decided not to do that for now
14:06:38  <piscisaureus>bnoordhuis: on windows it will just fail a recv operation
14:06:43  <piscisaureus>(says the docs)
14:06:44  <bnoordhuis>it's another syscall and what are you going to do anyway?
14:06:52  <piscisaureus>heh
14:07:12  <piscisaureus>I think atm the error gets reported to the udp_recv_cb
14:07:39  <bnoordhuis>only if it's reported directly by recvmsg
14:07:49  <bnoordhuis>but maybe i'll scratch that too
14:07:59  <bnoordhuis>i've only been able to trigger it on linux
14:08:10  <piscisaureus>I have not been able to trigger that
14:08:14  <bnoordhuis>and only with 'network down' kind of failures
14:08:30  <piscisaureus>if people see it I will back hole that error
14:08:40  <piscisaureus>bnoordhuis: btw http://www.powned.tv/nieuws/tech/2011/08/van_trouwen_word_je_dik.html
14:08:50  <bnoordhuis>old news!
14:10:30  <bnoordhuis>love the nuanced and insightful comments, truly view broadening
14:15:55  <piscisaureus>bnoordhuis: this is the society you live in.
14:16:50  <bnoordhuis>piscisaureus: good thing i work from home, i don't run into society often
14:18:08  <bnoordhuis>udp_packet_storm_1v1: 6785/s received, 6785/s sent
14:18:09  <bnoordhuis>udp_packet_storm_10v1: 6574/s received, 6574/s sent
14:18:09  <bnoordhuis>udp_packet_storm_100v1: 5346/s received, 5346/s sent
14:18:09  <bnoordhuis>udp_packet_storm_1000v1: 1465/s received, 1465/s sent
14:18:09  <bnoordhuis>udp_packet_storm_10v10: 9520/s received, 9522/s sent
14:18:09  <bnoordhuis>udp_packet_storm_100v10: 9074/s received, 9076/s sent
14:18:11  <bnoordhuis>udp_packet_storm_1000v10: 6080/s received, 6082/s sent
14:18:13  <bnoordhuis>udp_packet_storm_100v100: 9720/s received, 9740/s sent
14:18:15  <bnoordhuis>udp_packet_storm_1000v100: 9060/s received, 9080/s sent
14:18:17  <bnoordhuis>udp_packet_storm_1000v1000: 9400/s received, 9600/s sent
14:18:19  <bnoordhuis>^ freebsd :/
14:18:30  <bnoordhuis>but it's a puny machine so probably not a fair comparison
14:18:50  <bnoordhuis>numbers in my freebsd vm are similar
14:28:22  <CIA-75>libuv: Ben Noordhuis master * r6cc241a / include/uv.h : Fix 'incomplete prototype' compiler warnings on SunOS. - http://git.io/47UPUw
14:28:22  <CIA-75>libuv: Ben Noordhuis master * rd01676f / config-unix.mk :
14:28:23  <CIA-75>libuv: build: define _XOPEN_SOURCE=500 on SunOS
14:28:23  <CIA-75>libuv: Exposes msghdr.msg_flags, required for UDP support. - http://git.io/Hjyt0A
14:51:26  <bnoordhuis>piscisaureus: strong opinions on UV_UDP_REUSEADDR support?
14:51:30  <bnoordhuis>if not, i'm going to rip it out
15:15:51  <bnoordhuis>piscisaureus: it's gone :)
15:30:10  * ofcchanged nick to jne0
15:35:03  * jne0changed nick to jmp0
15:54:40  <jmp0>is there an easy way to add stdin to the uv event loop yet?
15:55:22  * rmustaccpart
15:57:58  <jmp0>i'm poking around a bit but the necessary functions and data structures doesn't seem exposed :P
15:58:42  <jmp0>and what's uv_std_handle supposed to be?
16:07:31  <DrPizza>it will happen at some point
16:07:43  <DrPizza>but there's complexity involved
16:08:17  <DrPizza>I don't think all the plumbing is in place yet.
16:08:56  <jmp0>i guess you need the pipes and flushes
16:09:28  <DrPizza>pipes are actually better supported than "real" console stdin/stdout at present
16:11:09  <jmp0>could try opeing a pipe a dup stdio to it
16:12:06  <DrPizza>there are various complications
16:12:11  <DrPizza>for example, win32 console I/O is all blocking
16:12:22  <DrPizza>win32 console I/O doesn't speak vt100
16:12:26  <DrPizza>etc.
16:16:58  <CIA-75>node: koichik master * r1adfd48 / doc/api/stdio.markdown : Doc improvements - http://git.io/R6uCWA
16:17:26  <CIA-75>node: koichik v0.4 * r509a676 / doc/api/stdio.markdown : Doc improvements - http://git.io/nmGjWg
16:23:45  <ryah>jmp0: not yet
16:26:14  <piscisaureus>bnoordhuis: re SO_REUSEADDR
16:26:22  <piscisaureus>bnoordhuis: I don't care
16:27:54  <piscisaureus>bnoordhuis: someone should give me a valid use case for SO_REUSEADDR first before I start caring
16:31:06  <ryah>bnoordhuis: i took the weekend off - got nothing done - sorry
16:31:35  <ryah>doing the npm bug today
16:49:54  <ryah>http://www.youtube.com/watch?v=i-QKkSXeRDQ
16:49:55  <ryah>:D
16:51:23  <piscisaureus>ah, nice
16:52:48  <piscisaureus>ryah: bnoodhuis: I would like uv_handle_t and uv_req_t to have a common base class
16:52:56  <piscisaureus>can we do this?
17:09:10  <ryah>piscisaureus: maybe
17:09:21  <ryah>piscisaureus: uv_close doesn't makes sense for uv_re_t
17:09:23  <ryah>req_t
17:09:49  <piscisaureus>ryah: I am not saying that a req should be a handle
17:10:00  <ryah>oh - okay
17:10:06  <ryah>what would you call it?
17:10:13  <piscisaureus>ryah: I just need them to have a common base clase - with a type in it and possible some private fields
17:10:33  <piscisaureus>ryah: eh, that's what I was thinking about too
17:10:41  <piscisaureus>what is an appropriate name for this
17:10:59  <piscisaureus>We don't necessarily need to expose this btw
17:11:16  <piscisaureus>it could be just internal
17:11:21  <piscisaureus>uv_base_t?
17:12:21  <ryah>what do you want to share?
17:12:30  <ryah>between req_t and handle_t ?
17:12:37  <ryah>unrelated:
17:12:38  <ryah>> require('path').existsSync('C:\\Windows\\')
17:12:38  <ryah>false
17:12:38  <ryah>> require('path').existsSync('C:\\Windows')
17:12:40  <ryah>true
17:12:51  <piscisaureus>a linked list
17:12:54  <piscisaureus>and the type
17:13:08  <ryah>ngx_queue_t ?
17:13:20  <piscisaureus>ryah, just a tail queue is good enough
17:13:43  <piscisaureus>so just `uv_base_t* next` probably
17:14:01  <ryah>(you should use ngx_queue_t - but that's besides the point)
17:14:08  <piscisaureus>why?
17:14:13  <ryah>because its there
17:14:27  <piscisaureus>oh I never did this
17:15:08  <piscisaureus>ryah: I guess existsSync calls stat under the hood?
17:15:15  <ryah>yes
17:15:43  <ryah>https://github.com/joyent/node/issues/1565
17:16:44  <ryah>> require('fs').statSync('C:\\Windows')
17:16:45  <ryah>{ dev: 2,
17:16:45  <ryah> ino: 0,
17:16:45  <ryah> mode: 16895,
17:16:45  <ryah> nlink: 1,
17:16:47  <ryah> uid: 0,
17:16:49  <ryah> gid: 0,
17:16:52  <ryah> rdev: 2,
17:16:54  <ryah> size: 0,
17:16:57  <ryah> atime: Fri, 05 Aug 2011 22:23:46 GMT,
17:16:59  <ryah> mtime: Fri, 05 Aug 2011 22:23:46 GMT,
17:17:02  <ryah> ctime: Tue, 14 Jul 2009 02:37:05 GMT }
17:17:04  <ryah>> require('fs').statSync('C:\\Windows\\')
17:17:07  <ryah>Error: ENOENT, The system cannot find the file specified. 'C:\Windows\'
17:17:09  <ryah> at Object.statSync (fs.js:401:18)
17:17:12  <ryah> at repl:1:15
17:17:14  <piscisaureus>ryah: ok
17:17:14  <ryah> at Interface.<anonymous> (repl.js:168:22)
17:17:17  <ryah> at Interface.emit (events.js:67:17)
17:17:19  <ryah> at Interface._onLine (readline.js:153:10)
17:17:22  <ryah> at Interface._line (readline.js:408:8)
17:17:24  <ryah> at Interface._ttyWrite (readline.js:585:14)
17:17:27  <ryah> at ReadStream.<anonymous> (readline.js:73:12)
17:17:29  <ryah> at ReadStream.emit (events.js:70:17)
17:17:32  <ryah> at onKeypress (tty_win32.js:46:10)
17:17:34  <ryah>is C:\Windows\ a valid path?
17:17:37  <ryah>it seems "ls" doesn't like it
17:17:54  <ryah>nevermind
17:17:58  <piscisaureus>ryah: it is -- if it is a directory
17:18:41  <piscisaureus>ryah: does existsSync work with "\\" or "c:\\"
17:19:06  <ryah>yes
17:19:19  <piscisaureus>hmm
17:19:30  <piscisaureus>naively stripping trailing whitespace won't work then
17:19:41  <piscisaureus>er, trailing slashes
17:21:39  <piscisaureus>ryah: do we want to fix this in the wake of ditching libev. A somewhat hacky solution for the moment would be to filter the path through path.resolve
17:21:51  <piscisaureus>that should do the right thing
17:22:00  <piscisaureus>for the moment
17:22:15  <ryah>do you think the CRT _stat is just broken?
17:22:19  <piscisaureus>yes
17:22:24  <piscisaureus>or maybe not
17:22:34  <ryah>it seems that way
17:22:39  <piscisaureus>let me look at the source
17:23:00  <ryah>http://permalink.gmane.org/gmane.comp.gnu.mingw.announce/799
17:23:46  <piscisaureus>that won't help if we use msvc
17:23:58  <ryah>i think we should let igor handle this in the libeio binding..
17:24:05  <piscisaureus>yeah +1
17:24:50  <ryah>igorzi: can you handle https://github.com/joyent/node/issues/1565 when you do the uv_async functions?
17:25:43  <piscisaureus>I wonder if we should do this broken "unix emulation" that crt's stat does
17:26:28  <piscisaureus>uxmode = (unsigned short)
17:26:28  <piscisaureus> (((ISSLASH(*p) && !p[1]) || (dosmode & A_D) || !*p)
17:26:28  <piscisaureus> ? _S_IFDIR|_S_IEXEC : _S_IFREG);
17:26:28  <piscisaureus> /* If attribute byte does not have read-only bit, it is read-write */
17:26:28  <piscisaureus> uxmode |= (dosmode & A_RO) ? _S_IREAD : (_S_IREAD|_S_IWRITE);
17:26:28  <piscisaureus> /* see if file appears to be executable - check extension of name */
17:26:28  <piscisaureus> if (p = _tcsrchr(name, _T('.'))) {
17:26:29  <piscisaureus> if ( !_tcsicmp(p, _T(".exe")) ||
17:26:29  <piscisaureus> !_tcsicmp(p, _T(".cmd")) ||
17:26:30  <piscisaureus> !_tcsicmp(p, _T(".bat")) ||
17:26:30  <piscisaureus> !_tcsicmp(p, _T(".com")) )
17:26:31  <piscisaureus> uxmode |= _S_IEXEC;
17:26:46  * rmustaccjoined
17:27:42  <ryah>piscisaureus: what's that?
17:27:57  <ryah>piscisaureus: is the CRT open source?
17:28:14  <piscisaureus>ryah: no crt stat
17:29:09  <piscisaureus>I wonder if we want to have to keep the "umode emulation" that crt does
17:29:22  <piscisaureus>it's kind of useless on windows
17:32:29  <piscisaureus>ah
17:32:45  <piscisaureus>stat.c calls FindFirstFile instead of GetFileAttributes
17:33:09  <piscisaureus>but if you give "c:\windows\" to FindFirstFile it'll return all the files in c:\windows
17:33:50  <igorzi>ryah: yeah, assign https://github.com/joyent/node/issues/1565 to me
17:34:30  <igorzi>piscisaureus: i'm going to back out the non-zero reads patch
17:34:43  <piscisaureus>igorzi: why?
17:35:05  <igorzi>piscisaureus: it's not working well with node's slab allocator
17:35:21  <piscisaureus>igorzi: keep it in - just change 50 to 0
17:35:32  <piscisaureus>and put in a comment why it is disabled
17:35:56  <igorzi>piscisaureus: ok, hopefully one day we'll change it back to 50
17:36:00  <piscisaureus>yeah
17:36:18  <piscisaureus>igorzi: I think there will be tweaks made to node's slab allocator
17:36:25  <piscisaureus>(ryah -- or?)
17:36:48  <piscisaureus>igorzi: btw, I can't get udp to work with 0 reads
17:37:15  <igorzi>piscisaureus: what happens?
17:37:41  <piscisaureus>igorzi: when doing the 0-read I set MSG_PARTIAL flag so it shouldn't discard the rest of the message
17:38:26  * brsonjoined
17:38:38  <piscisaureus>but if I make a nonblocking call to WSARecvFrom it always gives me WSAEWOULDBLOCK and ioctlsocket(FIONREAD) gives 0
17:38:48  <piscisaureus>so the kernel buffer is just empty
17:39:58  <piscisaureus>igorzi: there are a few more issues that must be solved, but let's discuss at the scrum call
17:40:01  <ryah>piscisaureus: rethinking how node allocs buffers would be wise
17:40:32  <piscisaureus>ryah: have you ever thought about making Buffer a subclass of Handle?
17:40:51  <ryah>node::Buffer ?
17:40:55  <piscisaureus>yes
17:40:58  <ryah>no
17:41:03  <piscisaureus>so you can have Handle<Buffer>
17:41:10  <ryah>ah
17:41:22  <ryah>yes that would be cool - im not sure how to do it
17:41:30  <ryah>it has to be a subclass of Value i think
17:41:34  <piscisaureus>yes
17:41:56  <piscisaureus>we should get a first opinion from mraleph
17:42:37  <ryah>piscisaureus, igorzi: openssl is building in trunk in gyp-openssl branch
17:42:42  <ryah>if you are interested in trying
17:45:25  <ryah>piscisaureus: you might like this http://www.erlang-factory.com/conference/ErlangFactoryLiteLA/speakers/UlfWiger
17:47:23  <piscisaureus>ryah: thnx will have a look
17:52:07  <ryah>i think we might add throttling to uv_stream_t at some point
17:52:31  <piscisaureus>ryah: why?
17:52:35  <CIA-75>libuv: Jeroen Janssen master * rce20791 / src/uv-unix.c :
17:52:35  <CIA-75>libuv: remove unused variable
17:52:35  <CIA-75>libuv: Fixes #151 - http://git.io/mlQxTA
17:53:01  <piscisaureus>ryah: libuv handle this is preferrable over the user doing it?
17:55:53  <ryah>uv_rate_limit(stream, 50.0, 50.0); // allows 50 KB/sec up and down
17:56:43  <ryah>i imagine a future where we can give priorities to each stream
17:56:48  <ryah>and auto limit them
17:57:01  <ryah>to prevent any stream from hogging the system
17:57:02  <rmustacc>I'd agree with piscisaureus there.
18:00:15  <igorzi>ryah: nice! i just built gyp-openssl branch.
18:00:45  <igorzi>ryah: are you planning to switch to vc-built node.exe for releases?
18:02:10  * graydonjoined
18:03:24  <ryah>igorzi: yeah - wrestling with if we should actually include openssl in the source
18:03:29  <ryah>it's kind of big :/
18:03:46  <ryah>most unix people also dont want it..
18:09:46  <DrPizza>ryah: yes, but what's the harm in it, really.
18:11:38  <ryah>it just pains me to increase the tarball by 12mb
18:11:50  <ryah>that's more than double
18:12:32  <pquerna>well, actually, unix people might want it.
18:12:39  <pquerna>to use NPN and other such feattures
18:12:49  <DrPizza>ryah: if we retain the patched openssl it's probably valuable even for unix
18:12:59  <pquerna>debian packaging it up wont want it, but random users might
18:13:18  <DrPizza>debian doesn't even use node's v8
18:13:26  <DrPizza>er
18:13:28  <DrPizza>ubuntu doesn't
18:13:31  <DrPizza>I assume debian is the same
18:13:36  <DrPizza>but ubuntu could have different packages I guess
18:13:41  <ryah>currently tarball = 6mb
18:13:54  <DrPizza>what's the zipped size
18:13:57  <pquerna>bandwidth is cheap, you work for a hosting company :)
18:13:59  <ryah>.tar.gz
18:14:16  <DrPizza>is that HEAD or the entire history?
18:14:21  <pquerna>head
18:14:23  <ryah>im not worried about the bandwidth - just people's perceptions when downloading
18:14:43  <ryah>6mb = clean managable
18:15:05  <ryah>18mb = sloppy
18:15:07  <ryah>:)
18:15:48  <pquerna>so, i take it you really like it when maven downloads 200mb of Jar files to run one task
18:15:52  <ryah>also im pretty sure we want to dynamically link for almost all unix users
18:16:02  <ryah>to the system libssl
18:16:02  <DrPizza>wait, the openssl .tgz is only 4 MB
18:16:19  <DrPizza>how can adding openssl be adding 12 MB?
18:16:29  <ryah>DrPizza: oh - right - i was meassuring unziped
18:16:33  <DrPizza>oh
18:16:48  <ryah>it would be 6 + 4 = 10mb
18:16:50  <ryah>i guess that's not bad
18:16:59  <ryah>sigh.
18:17:33  <ryah>we could just have openssl as a git submodule
18:17:40  <ryah>and not include it for the unix builds
18:17:40  <DrPizza>ugh
18:17:49  <DrPizza>I would rather have a slightly larger checkout
18:17:55  <DrPizza>than a checkout that didn't reliably grab all the source I needed
18:18:16  <ryah>yeah - me too generally
18:18:37  <ryah>alright - i'll merge - fuck it
18:18:47  <DrPizza>ryah: do we have any idea what typical distros do for their libssls?
18:18:49  <DrPizza>do they tend to run stock?
18:19:02  <DrPizza>or do they include things like the fast handshake, npn, etc. patches?
18:19:19  <ryah>DrPizza: i guess they have stock distributions...
18:19:27  <ryah>no idea though
18:19:45  <pquerna>they run old stock
18:19:53  <pquerna>most don't have 1.0 yet
18:20:03  <pquerna>and def don't ahve fast handhsake or npn patches
18:20:10  <DrPizza>it looks like the patches like npn won't even be in stock until 1.1
18:20:55  <ryah>i wonder what chrome uses openssl for
18:21:01  <DrPizza>it doesn't
18:21:05  <DrPizza>I was asking the chromium people about it
18:21:11  * mralephjoined
18:21:11  <DrPizza>it explains why their openssl is so out of date
18:21:15  <ryah>yeah they use nss afaik
18:21:16  <DrPizza>it was in there experimentally
18:21:21  <DrPizza>they use NSS IRL
18:21:30  <DrPizza>openssl was there for some dude to test some stuff, or something
18:21:57  <ryah><evmar> i think we use [openssl] on windows
18:22:17  <DrPizza>if they do then they use openssl with known security flaws
18:22:17  <ryah><evmar> we hilariously have three ssl impls in chrome :(
18:22:19  <piscisaureus>hmm I think they use cryptoapi
18:22:30  <ryah><evmar> nss, openssl, and uh
18:22:37  <ryah><evmar> wait, no, that's regex engines
18:22:38  <ryah>:)
18:22:41  <DrPizza>piscisaureus: you'd have thought so, so they could get standard windows cert management etc.
18:23:19  <DrPizza>(which chrome depends on, it doesn't have its own private certificate store I don't believe)
18:23:53  <piscisaureus>ryah: DrPizza: http://src.chromium.org/viewvc/chrome/trunk/src/crypto/encryptor_win.cc?revision=91803&view=markup
18:24:26  <piscisaureus>also http://src.chromium.org/viewvc/chrome/trunk/src/crypto/hmac_win.cc?revision=88049&view=markup
18:24:45  <piscisaureus>they also have something special for mac
18:24:47  <ryah>piscisaureus: what is this?
18:25:21  <ryah>apparently they use it for andorid
18:25:22  <ryah>http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/net/base/openssl_private_key_store_android.cc&exact_package=chromium&q=openssl%20-file:third_party&type=cs
18:25:31  <piscisaureus>ryah: the crypto that chrome uses in windows
18:25:37  <ryah>OpenSSLKeyStoreAndroid
18:25:43  <DrPizza>does chrome do its own ssl handshaking?
18:25:52  <DrPizza>so it just uses the OS for encryption?
18:26:06  <ryah>i'm pretty sure it uses NSS...
18:26:26  <piscisaureus>http://src.chromium.org/viewvc/chrome/trunk/src/crypto/
18:27:28  <DrPizza>ah yeah it looks like it has paths for NSS and openssl
18:27:30  <DrPizza>for ssl sockets
18:27:33  <ryah>god i wish we didn't have openssl...
18:27:49  <ryah>if only there was a reasonable ssl implementation
18:28:03  <DrPizza>the alternative is to use native win32 ssl
18:28:12  <piscisaureus>it's not an alternative
18:28:14  <DrPizza>but that means no npn, not fast start handshakes, etc.
18:28:18  <piscisaureus>because it works only on windows
18:28:26  <DrPizza>piscisaureus: and libssl on other platforms
18:28:38  <ryah>when can we switch to selene?
18:28:40  <ryah>:~(
18:33:48  <piscisaureus>drop ssl, let people use a proxy
18:33:57  <piscisaureus>probably much faster
18:34:41  <ryah>it's really nice to be able to do ssl in node
18:37:18  <DrPizza>I think ssl is way too important to not do in node
18:37:52  <ryah>i have to run in order to make the call. bbiab.
18:38:19  <CIA-75>node: Ryan Dahl master * re80cac6 / (1579 files in 122 dirs): import openssl from chrome - http://git.io/1XKlCQ
18:38:19  <CIA-75>node: Peter Bright master * r0110c90 / (113 files in 40 dirs):
18:38:19  <CIA-75>node: Upgrade to 0.9.8r.
18:38:19  <CIA-75>node: Build in Win32. - http://git.io/VJd4iA
18:38:20  <CIA-75>node: Ryan Dahl master * r2e5a8e0 / LICENSE : Update license info for openssl - http://git.io/Ms9A5g
18:49:57  <piscisaureus>ryah: ping me just before calling
18:50:05  <piscisaureus>so I can set up
18:55:36  <bnoordhuis>bundling openssl? heresy!
18:55:56  <bnoordhuis>i'm warming to the idea actually, seeing that ubuntu 10.04 still ships 0.9.8k
18:56:19  <bnoordhuis>so... call time?
19:21:41  <bnoordhuis>ryah: https://github.com/bnoordhuis/node/compare/udp <- still wip though
19:22:36  <igorzi>piscisaureus: how about talking in an hour or so?
19:25:37  <piscisaureus>igorzi: right, ok
19:26:51  <piscisaureus>igorzi: you have a branch where you use SlowBuffers all the time
19:27:21  <piscisaureus>?
19:27:43  <piscisaureus>(hang on to it!)
20:25:18  * rmustaccpart
20:48:01  <igorzi>piscisaureus sorry, i don't have that anymore.. i was just creating a new buffer with Buffer::New() everytime.
20:54:59  <piscisaureus>igorzi: oh ok hmm
20:55:09  <piscisaureus>igorzi: wrt to WSAGetOverlappedResult
20:57:25  <piscisaureus>this is where it goes wrong:
20:57:25  <piscisaureus>- user calls uv_write(h, buf)
20:57:25  <piscisaureus>- (the writes completes, gets queued to the iocp)
20:57:25  <piscisaureus>- the user calls uv_close(h), which calls closesocket
20:57:25  <piscisaureus>- libuv dequeues the write packet, calls uv_process_tcp_write_req
20:57:26  <piscisaureus>- uv_process_tcp_write_req calls WSAGetOverlappedResult(h->socket) <-- boom!
20:59:35  <igorzi>hmm, can closesocket be moved to endgame?
21:00:02  <piscisaureus>igorzi: no because we need to cancel pending requests, e.g. the read/accept req etc
21:00:08  <piscisaureus>or - maybe it could
21:00:11  <piscisaureus>but painful
21:00:31  <piscisaureus>igorzi: we can have our own NTSTATUS->error mapping -- Just like the msafd implementation of WSPGetOverlappedResult which uses SockNtStatusToSocketError
21:00:49  <piscisaureus>igorzi: but that might in theory not correct if people use something else than msafd
21:00:54  <piscisaureus>but this seems highly theoretical to me
21:03:46  <igorzi>hmm, that at the moment seems to the the only solution, right? (other than moving closesocket to endgame)
21:03:56  <piscisaureus>yes i guess
21:04:03  <piscisaureus>is it very bad
21:04:14  <piscisaureus>there may be other loopholes we can exploit
21:07:10  <CIA-75>node: Maciej Małecki issue1531 * r57173d7 / test/simple/test-https2-compatibility.js : Test for https2 compatibility (issue #1531) - http://git.io/j7aF5A
21:07:10  <CIA-75>node: Mikeal Rogers issue1531 * r7e32ef5 / (lib/http2.js lib/https2.js): Fixes #1531 - http://git.io/iNQz3Q
21:16:46  <piscisaureus>igorzi: can you figure out whether MSG_PARTIAL works for udp at all?
21:17:01  <piscisaureus>igorzi: the msdn documentation seems to suggest it does
21:17:23  <piscisaureus>but there is no way at all I can get windows to use not return that flag
21:17:53  <piscisaureus>(I mean, it's an in-out flag. But it's not consumed nor returned)
21:18:00  <igorzi>piscisaureus: there's HRESULT_FROM_NT.. i wonder if we could do something with that
21:18:45  <piscisaureus>igorzi: I think there is also a NT_SUCCESS (or similar) macro
21:19:04  <piscisaureus>igorzi: but there is no guarantee that a WSP should use the Internal field at all
21:19:19  <igorzi>piscisaureus: MSG_PARTIAL doesn't work with overlpped and non-overlapped, right?
21:19:29  <piscisaureus>igorzi: yes
21:19:36  * indutnyjoined
21:19:42  <piscisaureus>igorzi: I was trying blocking calls, for that it doesn't seem to work either
21:20:17  <igorzi>piscisaureus: is the udp code up somewhere?
21:20:30  <piscisaureus>igorzi: it's a bit messy but yeah
21:20:35  <piscisaureus>I'm going to put it up now
21:24:11  <piscisaureus>igorzi: https://github.com/piscisaureus/libuv/tree/udp
21:24:11  <piscisaureus>Note: this has uv_active_udp_streams_threshold = 999999 so non-0 reads are disabled
21:24:11  <piscisaureus>also, it may not be suitable to send to someone. I guess you'd want to have a 'reduced' case for that.
21:24:45  * mralephquit (Quit: Leaving.)
21:26:22  <igorzi>piscisaureus: yep, i'm just going to narrow this down to MSG_PARTIAL issue
21:27:25  <piscisaureus>igorzi: don't you have an internal bug tracker at msft that you can search btw?
21:27:42  <igorzi>piscisaureus: nothing came up :)
21:28:21  <piscisaureus>I think there is a reasonable chance that nobody ever uses MSG_PARTIAL
21:35:33  <CIA-75>node: Maciej Małecki master * r94963ab / test/simple/test-regress-GH-1531.js :
21:35:33  <CIA-75>node: Add failing test for https2 compatibility
21:35:33  <CIA-75>node: Issue #1531 - http://git.io/FPaHxA
21:35:33  <CIA-75>node: Mikeal Rogers master * r103990b / (lib/http2.js lib/https2.js): Fixes #1531 - http://git.io/55ZzlA
21:49:47  <ryah>ryan@mac1234:~/projects/node% ./node --use-uv test/simple/test-regress-GH-1531.js
21:49:47  <ryah>200
21:49:47  <ryah>Assertion failed: (!ev_is_active(&stream->read_watcher)), function uv__read, file src/uv-unix.c, line 850.
21:49:50  <ryah>zsh: abort ./node --use-uv test/simple/test-regress-GH-1531.js
21:52:57  <bnoordhuis>i think one of the tls tests also triggers that assertion
21:54:08  <ryah>im going to upgrade libuv now
22:02:52  <bnoordhuis>every time i step out into the backyard after dark i kill like a 100 snails
22:03:01  <bnoordhuis>the soles of my shoes are a veritable snail graveyard...
22:03:15  <bnoordhuis>sorry little snails, i didn't mean to :(
22:03:42  <ryah>lovely
22:03:47  <CIA-75>node: Ryan Dahl master * rb8d40be / (31 files in 6 dirs): Upgrade libuv to joyent/libuv@ce20791 - http://git.io/u1QBGw
22:03:47  <CIA-75>node: Ryan Dahl master * rcf2e68d / lib/net_uv.js : net_uv: handle read errors - http://git.io/penRqg
22:04:00  <ryah>bnoordhuis: natural selection
22:04:15  <ryah>evolution will teach them not to go in your backyar
22:04:50  <bnoordhuis>but it'll take a million years
22:04:54  <bnoordhuis>snails are not fast learners
22:12:56  <DrPizza>they're not fast at anything, really.
22:13:01  <DrPizza>but they are hermaphrodites.
22:13:03  <DrPizza>which is rather exciting.
22:22:19  <bnoordhuis>i bet you visit thailand regularly?
22:22:54  <ryah>thailand has many hermaphrodites?
22:23:16  <DrPizza>lol
22:23:31  <piscisaureus>bnoordhuis: what ryah asked
22:23:42  <bnoordhuis>well... i don't want to have to explain it
22:24:00  <bnoordhuis>at piscisaureus, watch that one metropolis episode and you'll understand
22:24:19  <piscisaureus>bnoordhuis: there are many transvestites probably but many hermaphrodites?
22:29:58  * isaacsjoined
22:30:25  <bnoordhuis>piscisaureus: you know, i think deferred socket creation wasn't such a good idea after all
22:30:49  <piscisaureus>waai?
22:30:53  <bnoordhuis>the current dgram module in node lets you receive packets immediately
22:31:28  <bnoordhuis>immediately after `new dgram.Socket('udp4', listener)` i mean
22:31:58  <piscisaureus>Emitted when a socket starts listening for datagrams. This happens as soon as UDP sockets are created. Unix domain sockets do not start listening until calling bind() on them.
22:32:12  <bnoordhuis>i suppose i should cheat and add a bind('', 0) to the Socket constructor
22:32:50  <piscisaureus>bnoordhuis: weird
22:33:02  <piscisaureus>so you can bind after you've started reading?
22:33:24  <bnoordhuis>piscisaureus: you mean now or with libuv?
22:33:28  <piscisaureus>bnoordhuis: now
22:33:38  <bnoordhuis>piscisaureus: yeah
22:33:39  <piscisaureus>bnoordhuis: I don't think we can make this work on windows
22:34:15  <bnoordhuis>piscisaureus: you mean a bind is like diamonds, i.e. forever?
22:34:30  <piscisaureus>would it not?
22:34:46  <bnoordhuis>well, you can't unbind on unices
22:34:46  <piscisaureus>or - would it be allowed to bind() while an overlapped read is in flight?
22:35:13  <bnoordhuis>that'd work on the unices
22:35:26  <bnoordhuis>binding is separated from reading and writing
22:35:34  <piscisaureus>bnoordhuis: you can't bind again on windows
22:36:30  <bnoordhuis>piscisaureus: oh man
22:36:31  <piscisaureus>bnoordhuis: also, I can't call WSARecvFrom with an unbound socket
22:36:34  <piscisaureus>so
22:36:41  <piscisaureus>this is not going to work
22:36:57  <bnoordhuis>so what *can* windows do?
22:37:13  <piscisaureus>this api was a mistake
22:37:14  <piscisaureus>ryah!
22:37:32  <ryah>what?
22:37:53  <piscisaureus>node's udp api can't work on windows
22:37:59  <DrPizza>why not
22:38:10  <piscisaureus>node starts listening immediately after creating an UDP socket
22:38:18  <piscisaureus>but you can bind after that
22:38:44  <bnoordhuis>piscisaureus: but how does node's udp support work on windows now?
22:38:51  <DrPizza>so you can create an AF_INET, SOCK_DGRAM socket in node
22:38:53  <DrPizza>on unix
22:38:54  <piscisaureus>*shrug*
22:38:54  <bnoordhuis>the current dgram module starts an iowatcher
22:39:00  <DrPizza>and what data does it receive?
22:39:04  <DrPizza>how does it receive it?
22:39:10  <piscisaureus>I don't know
22:39:13  <piscisaureus>probably it uses select
22:39:14  <DrPizza>it's just automatically listening on a random port?
22:39:31  <bnoordhuis>DrPizza: where those questions for me?
22:39:36  <DrPizza>for anyone who knows
22:39:43  <bnoordhuis>right
22:39:43  <piscisaureus>does it even work?
22:39:58  <DrPizza>bnoordhuis: is that how receiving data on unbound sockets works?
22:40:04  <bnoordhuis>DrPizza: when the dgram socket's created, it gets assigned a random port and it's bound to
22:40:16  <DrPizza>I see
22:40:27  <DrPizza>that sounds like a useless shortcut but OK
22:40:34  <DrPizza>so why not bind Windows' to
22:40:48  <bnoordhuis>yeah, that's the cheat i proposed
22:41:04  <bnoordhuis>but according to piscisaureus you can't rebind later on
22:41:08  <piscisaureus>that's what we do
22:41:08  <DrPizza>so what
22:41:11  <DrPizza>just create a new socket
22:41:34  <bnoordhuis>and on unix it probably has the drawback that you'd be listening on the random port and the port you want
22:42:02  * isaacs_joined
22:42:03  <bnoordhuis>i'd have to check if all unices actually unbind the old address when you rebind
22:42:42  <DrPizza>piscisaureus: what does Windows do if you try to re-bind()?
22:42:50  <bnoordhuis>no, you get EINVAL :(
22:43:05  <DrPizza>oh right
22:43:05  <DrPizza>This error is returned of the socket s is already bound to an address.
22:44:46  * isaacsquit (Ping timeout: 260 seconds)
22:44:46  * isaacs_changed nick to isaacs
22:45:04  <DrPizza>so you can call WSARecvFrom if the socket is implicitly bound
22:45:07  <DrPizza>so if you send before receiving
22:45:12  <DrPizza>you don't need to bind()
22:45:39  <piscisaureus>hmm
22:45:53  <piscisaureus>maybe that's how it manages to sometimes work with the legacy backend
22:46:16  <DrPizza>you need to bind to receive without first sending (e.g. for a server)
22:46:22  <DrPizza>but that seems harmless enough
22:46:54  <DrPizza>I'm not quite clear on the use case of receiving unsolicited data on a UDP socket without listening on a known port
22:47:19  <bnoordhuis>DrPizza: well, it's far-fetched but...
22:47:40  <DrPizza>since you surely can't even know if the data was meant for your socket
22:47:49  <bnoordhuis>create a udp socket, get the address + port with sock.address() and send it over some other channel to a third party
22:48:04  <bnoordhuis>third party starts sending dgrams to address + port
22:48:38  <piscisaureus>bnoordhuis: hmm questionable
22:48:57  <piscisaureus>bnoordhuis: you are saying that upon creating of a udp socket node immedately starts listening on a random port?
22:48:59  <DrPizza>bnoordhuis: that sounds of dubious utility to me, but perhaps there is some use case that I am not aware of
22:49:20  <piscisaureus>bnoordhuis: that sounds really questionable to me
22:49:22  <bnoordhuis>some voip and video conferencing software works likes that
22:49:42  <piscisaureus>bnoordhuis:
22:49:42  <piscisaureus>dgram.bind(path)
22:49:42  <piscisaureus>For Unix domain datagram sockets, start listening for incoming datagrams on a socket specified by path. Note that clients may send() without bind(), but no datagrams will be received without a bind().
22:49:57  <bnoordhuis>yeah, that's for unix_dgram
22:50:02  <piscisaureus>ok
22:50:02  <piscisaureus>dgram.bind(port, [address])
22:50:02  <piscisaureus>For UDP sockets, listen for datagrams on a named port and optional address. If address is not specified, the OS will try to listen on all addresses.
22:50:23  <piscisaureus>bnoordhuis: I don't think it actually does listen without bind
22:50:29  <piscisaureus>and if it does, it is unintented
22:50:33  <DrPizza>bnoordhuis: that sounds most strange, especially as without the outbound traffic your NAT system won't even forward incoming traffic
22:50:44  <bnoordhuis>piscisaureus: yes, it does - it's how dgram sockets work on unix
22:51:00  <piscisaureus>bnoordhuis: soit
22:51:02  <piscisaureus>let people bind
22:51:19  <bnoordhuis>ryah: you okay with that?
22:51:22  <DrPizza>frankly I think you can leave it as a platform difference
22:51:31  <DrPizza>if it's really useful to listen on unbound sockets
22:51:36  <DrPizza>let them do so on unix
22:51:44  <piscisaureus>DrPizza: hmm
22:51:49  <DrPizza>clearly people writing Windows programs don't depend on that behaviour
22:51:59  <DrPizza>since Windows won't let you listen on an unbound socket
22:52:03  <piscisaureus>DrPizza: it would require node to call uv_udp_recv_start upon socket creation
22:52:04  <bnoordhuis>the point of libuv is that there are no platform differences
22:52:11  <piscisaureus>DrPizza: which implicitly binds on windows
22:52:52  <DrPizza>bnoordhuis: then the only option is to ban the behaviour under unix
22:53:02  <piscisaureus>I think it makes sense
22:53:16  <DrPizza>and require an explicit bind with bind(), or an implicit bind with send(), before you can listen
22:53:19  <bnoordhuis>DrPizza: i'd be okay with that but it's an api breaking change
22:53:31  <piscisaureus>If you want to bind to a random address, this is esoteric enough to let people think about what they're doing
22:53:41  <DrPizza>bnoordhuis: either you have an API-breaking change, or platform discrepancies
22:54:14  <DrPizza>it's only the socket() -> recv() case that breaks, and I would wager that case is rare
22:54:20  <DrPizza>socket() -> send() -> recv() is fine
22:54:26  <bnoordhuis>piscisaureus: just to be sure, you *have* to bind on windows to receive dgrams?
22:54:27  <DrPizza>socket() -> bind() -> recv() is fine
22:54:35  <DrPizza>bnoordhuis: implicitly or explicitly, yes.
22:54:54  <bnoordhuis>DrPizza: implicit means by sending a dgram?
22:54:57  <DrPizza>yes
22:55:04  <bnoordhuis>can you rebind after that?
22:55:13  <DrPizza>doubtful, but I don't see the utility
22:55:16  <DrPizza>just create a new socket
22:55:20  <bnoordhuis>doubtful is not good enough :)
22:55:38  <DrPizza>socket fds are never exposed to callers
22:55:41  <DrPizza>it doesn't matter if they change
22:55:57  <DrPizza>well, HANDLEs/SOCKETs, not "fds"
22:56:00  <ryah>bnoordhuis: which test is this breaking?
22:56:23  <bnoordhuis>ryah: nothing, i think
22:56:27  <bnoordhuis>i know what you're going to say :)
22:56:33  <ryah>that is - which test demos that we need to allow non-bound udp sockets?
22:57:15  <bnoordhuis>no, no test failing because of that
22:57:28  <bnoordhuis>but it's at odds with the documentation
22:57:40  <DrPizza>change the documentation, then
22:57:41  <DrPizza>easy fix
22:57:51  <bnoordhuis>fine by me
22:57:53  <piscisaureus>bnoordhuis: docs quote?
22:57:54  <DrPizza>"to listen on a UDP socket you must send data first, or else explicitly bind"
22:57:55  <DrPizza>:)
22:58:06  <piscisaureus>I don't see how it breaks
22:58:11  <piscisaureus>er
22:58:17  <bnoordhuis>piscisaureus: you mean what part of the docs mention that?
22:58:20  <piscisaureus>yes
22:58:30  <bnoordhuis>it's implied
22:58:42  <bnoordhuis>the unix dgram part says you need to bind to receive, the inet part doesn't
22:58:43  <DrPizza>I wouldn't infer it from the current docs
22:58:44  <bnoordhuis>ergo
22:58:45  <ryah>here is a quote from the docs
22:58:46  <ryah>dgram.bind(path)
22:58:46  <ryah>For Unix domain datagram sockets, start listening for incoming datagrams on a socket specified by path. Note that clients may send() without bind(), but no datagrams will be received without a bind().
22:59:01  <bnoordhuis>so we're going to update the docs?
22:59:07  <ryah>that sounds right
22:59:09  <bnoordhuis>(say yes, say yes) :)
22:59:13  <bnoordhuis>good
22:59:52  <piscisaureus>bnoordhuis: I don't see how the docs imply that you don't need to bind to receive messages
23:00:02  <piscisaureus>It is ambiguous at worst
23:00:12  <ryah>yeah, im confused
23:00:25  <bnoordhuis>really?
23:00:26  <ryah>bnoordhuis: can you make a diff of the doc change you want?
23:00:31  <bnoordhuis>sure
23:00:44  <DrPizza>ryah: on unix, apparently, you can do int s = socket(AF_INET, SOCK_DGRAM, ...), and then recvfrom(s, ...) and it works
23:00:49  <CIA-75>libuv: Igor Zinkovsky master * r4e9edce / src/win/tcp.c : windows: temporarily disable non-zero reads - http://git.io/yYMUsg
23:00:49  <DrPizza>ryah: on Windows, you cannot
23:01:06  <DrPizza>ryah: the current documentation says nothing explicit about this situation
23:01:19  <DrPizza>but it's implicitly permitted, insofar as it's not explicitly forbidden
23:01:27  <DrPizza>for unix domain sockets, it's explicitly forbidden
23:01:49  <bnoordhuis>^ what peter said
23:02:01  <ryah>DrPizza: i think the intended behavior is socket(), sendmsg(), recvfrom()
23:02:08  <igorzi>ryah: please include https://github.com/joyent/libuv/commit/4e9edceb980401d92d45710a07b00872b430fd12 when you update libuv
23:02:14  <ryah>igorzi: k
23:02:16  <DrPizza>ryah: yes, if we make it so that the only permitted sequences are:
23:02:21  <DrPizza>socket() sendto() recvfrom()
23:02:25  <DrPizza>socket() bind() recvfrom()
23:02:27  <ryah>igorzi: i already upated - but we'll do it again soon
23:02:30  <DrPizza>then we're in the clear, both platforms are the same
23:02:40  <DrPizza>it just requires the documentation to be tightened up
23:02:57  <ryah>the issue is that if you send on windows - you don't get assigned a port?
23:03:16  <ryah>you must..
23:03:17  <DrPizza>no, the issue is that on windows you can't recvfrom() without one of: bind(), sendto()
23:03:29  <ryah>ah
23:03:33  <DrPizza>but bnoordhuis says that on unix, you can simply socket() recvfrom()
23:03:37  <DrPizza>and it'll listen on a random port
23:03:41  <ryah>ok
23:03:48  <ryah>yes - we should go with the windows behavior
23:03:52  <ryah>thanks for the summary DrPizza :)
23:03:57  <DrPizza>ok :)
23:04:25  <ryah>on windows sendto() will still assign a random port?
23:04:28  <DrPizza>yes.
23:04:41  <DrPizza>you don't need to bind() if you do a sendto()
23:04:47  <ryah>yeah - sounds fine
23:05:19  <DrPizza>which for clients is generally what you want, they shouldn't ever bind()
23:05:24  * isaacsquit (Quit: isaacs)
23:10:32  <piscisaureus>igorzi: do we put something similar to this -- https://gist.github.com/1163880 -- in libuv?
23:15:58  <ryah>i've been thinking
23:16:11  <ryah>it would be nice to have a "accept connection in new context" feature
23:16:19  <bnoordhuis>ryah piscisaureus DrPizza: https://gist.github.com/9745d48660204c3c7561 <- dgram api docs update
23:16:36  <igorzi>piscisaureus: i guess we could have a mapping like this, we don't want to try to move closesocket to endgame, right?
23:16:51  <piscisaureus>igorzi: I'd rather not move closesocket to endgame
23:17:17  <piscisaureus>igorzi: although we could if we kept track of all outstanding requests and call CancelIo on them
23:17:40  <ryah>bnoordhuis: can bind("", 0) be changed to bind()? Why ":::0" instead of "::0" ?
23:18:20  <ryah>bnoordhuis: how is bind("", 0) going to be done in windows? :/
23:18:48  <DrPizza>ipv4-only on 2003, dualstack on everything else, I guess?
23:20:05  <piscisaureus>igorzi: also I have been thinking about this
23:20:24  <bnoordhuis>ryah: somehow i always mistype ::0
23:20:31  <bnoordhuis>yet another reason why ipv6 will fail!
23:20:46  <piscisaureus>igorzi: GetQueuedCompletionStatus *also* looks at overlapped.Internal to determine if the request failed
23:20:53  <bnoordhuis>and sure, bind() works too - i'll update the docs
23:21:09  <piscisaureus>igorzi: so if a lsp doesn't use the Internal field then GetQueuedCompletionStatus will be unreliable
23:21:28  <DrPizza>the only LSPs that dont' work as expected are likely to be malware anyway
23:21:55  <piscisaureus>DrPizza: it is not "as expected"
23:22:03  <piscisaureus>there is no specification that says lsps have to use that field
23:22:27  <bnoordhuis>hey, it's actually in the api docs
23:22:29  <bnoordhuis>Close the underlying socket and stop listening for data on it. UDP sockets
23:22:29  <bnoordhuis>automatically listen for messages, even if they did not call `bind()`.
23:22:33  <DrPizza>if they don't do what regular winsock with no 3rd party LSPs does, for regular IP connections, they're unexpected.
23:22:40  <DrPizza>:p
23:22:54  <piscisaureus>actually GetQueuedCompletionStatus sets GetLastError() to the wrong error if a socket operation failed
23:23:07  <piscisaureus>From which follows
23:23:38  <piscisaureus>that we can't possible be more stupid about this that windows itself
23:23:46  <piscisaureus>*than
23:30:00  <ryah> peerfd = accept4(sockfd, saddr, &slen, SOCK_NONBLOCK | SOCK_CLOEXEC);
23:30:03  <ryah>^-- bnoordhuis cool
23:30:34  <bnoordhuis>ryah: thank ulrich drepper :)
23:35:44  <ryah>is that a syscall?
23:35:59  <ryah>yes - seems so
23:36:13  <bnoordhuis>yeah
23:36:18  <bnoordhuis>ulrich submitted the patches to the lkml in 2006 or 2007
23:36:40  <bnoordhuis>he's not all bad, ulrich is
23:39:21  <ryah>yes, i like his "introduction to memory for programmers" paper
23:44:31  <bnoordhuis>pretty great paper, even if it's heavy going at times
23:54:38  * isaacsjoined
23:58:18  <ryah>sweet!
23:58:18  <ryah>http://code.google.com/p/gyp/source/detail?r=1009
23:59:29  <bnoordhuis>haha, you like ninja don't you?