00:10:53  * Windenjoined
00:13:07  * Jacob8432quit (Quit: Leaving)
00:13:42  * Jacob843joined
00:14:16  * Windenquit (Quit: Leaving.)
00:49:59  * bnoordhuisquit (Ping timeout: 276 seconds)
01:05:07  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
01:25:48  * bradleymeckquit (Quit: bradleymeck)
01:55:50  * bnoordhuisjoined
01:58:01  * jgijoined
02:00:43  * bnoordhuisquit (Ping timeout: 260 seconds)
02:18:16  * jgiquit (Quit: jgi)
03:10:22  * evanluca_quit (Read error: Connection reset by peer)
03:10:37  * evanlucasjoined
03:15:47  * evanluca_joined
03:16:44  * evanlucasquit (Read error: Connection reset by peer)
03:29:04  * fourqchanged nick to fourq|away
03:29:08  * fourq|awaychanged nick to fourq
03:36:07  * rmgquit (Remote host closed the connection)
03:53:18  * jgijoined
03:54:02  * evanluca_quit (Read error: Connection reset by peer)
03:54:16  * evanlucasjoined
04:33:39  * tunniclmquit (Ping timeout: 265 seconds)
04:36:41  * rmgjoined
04:40:55  * rmgquit (Ping timeout: 240 seconds)
05:28:41  <kellabyte>valgrind is detecting a "Process terminating with default action of signal 13 (SIGPIPE)" when I call uv_write() sometimes, any ideas why that could be?
05:28:49  <kellabyte>it seems to be when a benchmark is completing
05:48:52  * jgiquit (Quit: jgi)
06:30:39  * rmgjoined
06:34:55  * rmgquit (Ping timeout: 240 seconds)
06:59:44  * happy-dudequit (Quit: Connection closed for inactivity)
07:30:43  * evanlucaschanged nick to EVANLUCAS
07:31:06  * EVANLUCASchanged nick to EVANLUCAS123
07:32:23  * EVANLUCAS123changed nick to evanlucas
07:35:56  * evanlucaschanged nick to EVANLUCAS123
07:38:15  * zju1joined
07:53:30  * MoZu4k__quit (Quit: MoZu4k__)
08:12:51  * rmgjoined
09:18:42  * evanlucasjoined
09:18:57  * EVANLUCAS123quit (Read error: Connection reset by peer)
09:23:37  * davijoined
09:23:37  * daviquit (Changing host)
09:23:37  * davijoined
09:40:20  <saghul>kellabyte: you need to ignore sigpipe
09:40:27  <saghul>libuv doesn't do it automatically
09:40:46  <saghul>otherwise when you try to write to a closed socket SIGPIPE will be sent and the process will be terminated
09:41:48  <saghul>kellabyte: the test runner does it, for example: https://github.com/libuv/libuv/blob/v1.x/test/runner-unix.c#L54
10:24:33  * rmgquit (Remote host closed the connection)
10:25:02  * seishunjoined
10:33:53  <indutny>saghul: I'm curious if we could do it for users automatically
10:34:05  <indutny>saghul: or at least expose cross-platform function to do so
10:38:17  * rendarjoined
10:39:05  * toothrotquit (Ping timeout: 260 seconds)
10:46:35  * toothrotjoined
11:14:13  * amurzeaujoined
11:25:11  * rmgjoined
11:26:33  <daurnimator>indutny: indeed
11:26:49  <daurnimator>IIRC on every platform except linux there is a flag for it
11:30:30  * rmgquit (Ping timeout: 250 seconds)
13:21:21  * tunniclmjoined
13:55:35  * alexforsterjoined
14:56:35  * evanlucasquit (Read error: Connection reset by peer)
14:57:14  * evanlucasjoined
15:23:31  * amurzeau_joined
15:26:53  * bradleymeckjoined
15:49:05  <amurzeau_>is someone already working on issue Enable Fast TCP Loopback on Win #489 ?
15:49:41  <saghul>indutny: we do it on BSDs with the available setsockopt
15:49:53  <saghul>not sure about windows
15:49:53  * bradleymeckquit (Quit: bradleymeck)
15:50:07  <saghul>amurzeau_: nope, feel free to work on it! :-)
15:50:28  <saghul>indutny: the problem I see is that on Linux we would turn it on for the entire process
15:51:07  <amurzeau_>fast loopback exists on other platforms too without being enable by default ?
15:51:47  <amurzeau_>ah you were not replying to me ignore my message :)
15:51:49  * fourqchanged nick to fourq|away
15:52:41  <saghul>amurzeau_: AFAIS it's only a Windows thing
15:52:53  <saghul>sorry if I mixed up the replies :-)
15:55:32  * fourq|awaychanged nick to fourq
15:55:40  <amurzeau_>saghul: I'm not sure how to implement fast loopback: should it be enabled on demand (like keepalive and nodelay) or enable it automatically (and ignore possible errors if not supported)
15:55:57  <amurzeau_>saghul: msdn says "Applying SIO_LOOPBACK_FAST_PATH to a socket which will be connected to a non-loopback path will have no effect."
16:01:17  <saghul>amurzeau_: I'd enable it always when binding to localhost, and ignore errors
16:11:55  * ncthom91joined
16:14:59  * ncthom91quit (Client Quit)
16:31:55  * evanlucasquit (Read error: Connection reset by peer)
16:32:20  * evanlucasjoined
16:50:28  * alexforsterquit (Quit: Textual IRC Client: www.textualapp.com)
16:54:58  * fourqchanged nick to fourq|away
16:55:00  * fourq|awaychanged nick to fourq
16:57:15  * thefourtheye__joined
16:58:59  * fourqchanged nick to fourq|away
17:03:42  * nickleeflyjoined
17:04:37  * txdv_changed nick to txdv
17:04:58  <amurzeau_>saghul: about fast path, I check how other projects implemented this:
17:05:20  <amurzeau_>openjdk apply it for all sockets if system property is set (so not active by default) (http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5c858af5ee9a)
17:06:41  <amurzeau_>MSOpenTech/redis and stackexchange.redis always enable it on windows 8/server 2012 +
17:08:06  <amurzeau_>also, I found that keepalive and nodelay or not supported with fast path active (I think because these options are not applicable in this case)
17:11:51  <amurzeau_>saghul: so not sure if we should enable it by default or be safe and let the use enable it (with a new function like uv_tcp_fastloopback)
17:12:59  <amurzeau_>saghul: typo: let the /user/ enable it
17:17:47  * benjamingr_joined
17:43:24  * jgijoined
17:47:36  * evanlucasquit (Read error: Connection reset by peer)
17:47:42  * evanluca_joined
17:54:53  * jgiquit (Quit: jgi)
17:59:23  * jgijoined
18:08:37  * jgiquit (Quit: jgi)
18:28:58  * rmgjoined
18:31:14  * amurzeau__joined
18:32:13  * amurzeau_quit (Ping timeout: 252 seconds)
18:33:41  * rmgquit (Ping timeout: 265 seconds)
18:36:08  * jgijoined
18:38:27  <amurzeau__>saghul: well, got blue screen while running run-tests.exe (after several benchmarks), windbg says it crashed in tcpip!TcpDeliverLoopbackDataToClient
18:39:44  <amurzeau__>saghul: so I will go for the manual way with a function like uv_tcp_fastloopback for now
18:45:45  * jgiquit (Quit: jgi)
18:46:31  * amurzeau__quit (Ping timeout: 252 seconds)
18:47:53  * amurzeau_joined
18:51:11  * jgijoined
18:51:44  * amurzeau_quit (Client Quit)
18:55:15  * jgiquit (Client Quit)
18:59:37  * Ralith_changed nick to Ralith
19:07:30  * rmgjoined
19:07:32  * rmgquit (Remote host closed the connection)
19:08:08  * rmgjoined
19:10:12  * jgijoined
19:12:35  * rmgquit (Ping timeout: 246 seconds)
19:13:29  * nickleeflyquit (Quit: Connection closed for inactivity)
19:21:11  * jgiquit (Quit: jgi)
19:59:41  * daviquit (Ping timeout: 250 seconds)
20:06:41  * amurzeau_joined
21:07:45  * gabrielschulhofjoined
21:08:16  <gabrielschulhof>Hey! What API can I use to get a callback when a file descriptor receives a POLLHUP?
21:08:37  <gabrielschulhof>... as per http://docs.libuv.org/en/v1.x/design.html?highlight=hangup
21:09:02  <gabrielschulhof>uv_poll_t only gives me read, write, and error ...
21:10:24  <gabrielschulhof>Oh, I see ... https://github.com/joyent/libuv/issues/623
21:30:40  * gabrielschulhofquit (Ping timeout: 260 seconds)
21:59:29  <saghul>amurzeau_: ok
22:04:25  * seishunquit (Ping timeout: 265 seconds)
22:08:12  * rmgjoined
22:12:35  * rmgquit (Ping timeout: 240 seconds)
22:27:23  * ncthom91joined
22:30:01  * ncthom91quit (Client Quit)
22:35:17  * ncthom91joined
22:36:56  * fourq|awaychanged nick to fourq
22:39:07  * ncthom91quit (Client Quit)
22:40:11  * rendarquit (Ping timeout: 265 seconds)
22:46:35  * rendarjoined
23:13:14  * ncthom91joined
23:37:39  * nickleeflyjoined
23:42:24  * amurzeau_quit (Ping timeout: 252 seconds)
23:45:31  * ncthom91quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:52:57  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
23:59:06  * Damn3dquit (Ping timeout: 240 seconds)