00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:00:51  * iarnaquit (Remote host closed the connection)
00:04:11  * c4miloquit (Remote host closed the connection)
00:05:13  * c4milojoined
00:10:07  * c4miloquit (Ping timeout: 264 seconds)
00:12:04  <jgi>trevnorris: ping
00:12:09  * quijotejoined
00:14:35  * seishunquit (Read error: Connection reset by peer)
00:17:15  * quijotequit (Ping timeout: 272 seconds)
00:27:27  * stagasjoined
00:33:35  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:58:19  * chris_99quit (Quit: Ex-Chat)
01:04:08  * stagasquit (Ping timeout: 250 seconds)
01:12:39  * rjequit (Quit: Leaving...)
01:12:50  * quijotejoined
01:15:32  * rjejoined
01:17:22  * quijotequit (Ping timeout: 245 seconds)
01:25:40  <tjfontaine>ok so I'm going to go live here with v0.10.35
01:26:57  <tjfontaine>octetcloud: I am still reading backlog, but yes, vcbuild is fairly "dumb" and will regenerate the project files
01:27:37  <tjfontaine>octetcloud: really mostly should consider vcbuild as configure, and then we should train people to use vs directly or msbuild subsequently
01:28:06  * dsantiagojoined
01:30:04  <MI6>joyent/node: tjfontaine created tag v0.10.35 - http://git.io/7VlAAg
01:31:12  <MI6>joyent/node: Timothy J Fontaine v0.10 * fe20196 : Now working on 0.10.36 (+2 more commits) - http://git.io/YnP9nw
01:33:24  * avalanche123quit (Remote host closed the connection)
01:38:15  * ovefquit (Quit: leaving)
01:52:50  * rendarquit (Quit: Leaving)
02:13:27  <jgi>octetcloud: I didn’t have time to review your PRs today, unless someone reviews them before I come back from vacation, it will have to wait until January 5th at least :(
02:13:40  * quijotejoined
02:17:35  * jgiquit (Quit: jgi)
02:17:56  * quijotequit (Ping timeout: 244 seconds)
02:39:11  * jgijoined
02:40:32  * jgiquit (Client Quit)
02:43:00  * jgijoined
02:46:39  * jgiquit (Client Quit)
02:47:02  * jgijoined
02:55:42  * AvianFlujoined
03:11:02  * Fishrock123quit (Quit: Leaving...)
03:11:29  * jgiquit (Quit: jgi)
03:14:03  * AvianFluquit (Ping timeout: 244 seconds)
03:14:27  * quijotejoined
03:18:52  * quijotequit (Ping timeout: 240 seconds)
03:19:35  <octetcloud>tjfontaine: train me! I'll do it some other way, I just was following README
03:20:01  <octetcloud>jgi: enjoy your time off, good working getting 10.35 out
03:20:33  * andrehjrquit (Quit: Computer has gone to sleep.)
03:36:00  <srl295>jgi: enjoy time off!
03:36:04  * Left_Turnquit (Remote host closed the connection)
04:01:17  * octetcloudquit (Quit: WeeChat 1.0.1)
04:15:22  * quijotejoined
04:19:17  * quijotequit (Ping timeout: 240 seconds)
04:51:41  * dsantiagoquit (Quit: Leaving...)
05:06:02  * nickleeflyjoined
05:15:47  * quijotejoined
05:20:18  * quijotequit (Ping timeout: 256 seconds)
05:35:39  * jgijoined
05:37:22  <jgi>srl295: ping
06:08:17  * jgiquit (Quit: jgi)
06:09:05  * iarnajoined
06:16:43  * quijotejoined
06:19:14  * jgijoined
06:20:57  * quijotequit (Ping timeout: 240 seconds)
06:30:35  * jgiquit (Quit: jgi)
07:17:24  * quijotejoined
07:21:55  * quijotequit (Ping timeout: 252 seconds)
07:51:41  * [spoiler]joined
07:58:39  * saghuljoined
08:06:02  * hollandaisquit (Ping timeout: 258 seconds)
08:11:03  * hollandaisjoined
08:11:34  * iarnaquit (Remote host closed the connection)
08:18:10  * quijotejoined
08:22:47  * quijotequit (Ping timeout: 252 seconds)
08:27:23  <saghul>libuv 0.10.31 and 1.1.0 are out: https://groups.google.com/forum/#!topic/libuv/9pcr41-uKIw
08:33:56  * saghulquit (Ping timeout: 250 seconds)
08:40:44  * SergeiRNDjoined
08:48:37  * quijotejoined
08:59:48  * jreyno40_joined
09:00:33  * nickleeflyquit (Quit: Connection closed for inactivity)
09:06:09  * rendarjoined
09:21:14  * davijoined
09:21:15  * daviquit (Changing host)
09:21:15  * davijoined
09:26:13  * quijotequit (Ping timeout: 250 seconds)
09:28:19  * lanceballquit (Ping timeout: 244 seconds)
09:28:33  * Left_Turnjoined
09:28:35  * jreyno40_quit (Quit: jreyno40_)
09:35:45  * lanceballjoined
09:35:47  * saghuljoined
09:39:06  * chris_99joined
09:49:44  * quijotejoined
10:07:58  * quijotequit (Read error: Connection reset by peer)
10:08:09  * quijotejoined
10:37:20  * quijotequit (Ping timeout: 265 seconds)
10:49:28  * quijotejoined
10:52:05  * tparjoined
10:55:01  <tpar>Hello, I'm new to libuv and I have a question about uv_queue_work
10:55:36  <tpar>I've been playing around with walking a directory tree just as a "getting to know libuv" exercise, and I tripped over something I found surprising
10:57:08  <tpar>just to give some context: I looked at traversing a tree using uv_fs_scandir, and was creating new uv_fs_scandir requests to add to the loop from the context of the scandir callback
10:57:13  <tpar>that all worked fine
10:57:44  <tpar>then I tried doing something similar but using an opendir/lstat/readdir approach, and handing each subdirectory off to the threadpool to process
10:58:18  <tpar>each new subdirectory would queue a work item using uv_queue_work
10:58:40  <tpar>so at some point for a large enough tree I'd end up calling uv_queue_work from the context of the threadpool work function
10:58:49  <tpar>but this ended up with memory corruption!
10:59:14  <tpar>I dug into it a bit and found I could get rid of the memory corruption by wrapping a lock around my calls to uv_queue_work
10:59:55  <tpar>looking at the libuv code I can see why this is: both uv_fs_scandir and uv_queue_work call into uv__work_submit at the bottom, which is thread-safe
11:00:30  <tpar>but uv_fs_scandir also calls uv__req_register, which touches the loop internals without any serialisation
11:02:38  <tpar>I guess this was a bit of a surprise as a newcomer: although the manual quite explicitly states that the loop API isn't thread safe, I suppose I was lulled into a false sense of security by not having to worry about this when using the uv_fs_* apis
11:03:24  <tpar>so my question is: is the issue I found with uv_queue_work by design and as expected, or should uv__req_register actually be serialised?
11:06:15  <saghul>tpar: gtg, but in a nutshell, the work callback is executed in another thread, and none of the libuv APIs are thread safe
11:06:28  <saghul>you can do it in the done_cb
11:06:41  * saghulquit (Quit: Textual IRC Client: www.textualapp.com)
11:07:49  * SergeiRNDquit (Quit: Leaving.)
11:10:52  <tpar>ack, thanks saghul
11:11:23  * quijotequit (Ping timeout: 240 seconds)
11:11:52  <tpar>so I think done_cb is run from the context of the loop thread rather than the threadpool, and that's what makes it OK to queue up further work items there
11:12:11  * iarnajoined
11:16:29  * iarnaquit (Ping timeout: 245 seconds)
11:34:02  * FROGGS[mobile]quit (Ping timeout: 245 seconds)
11:35:32  * seishunjoined
11:35:59  * FROGGS[mobile]joined
11:40:16  * SergeiRNDjoined
11:41:39  <txdv>tpar: yes
11:41:47  <txdv>'the context' being the thread
11:43:30  <tpar>txdv: ok, so when I'm using e.g. the libuv fs code, the completion callback I get is analogous to the threadpool done_cb
11:44:16  <tpar>while the code that runs the actual filesystem syscall is done by a threadpool thread, which is analogous to the the work function in the uv_queue_work case
11:45:34  * stagasjoined
11:48:54  * quijotejoined
11:53:16  * quijotequit (Ping timeout: 250 seconds)
11:57:11  * zhpengjoined
12:08:09  * tarrudajoined
12:11:29  * tarrudaquit (Client Quit)
12:12:29  * tarrudajoined
12:36:32  <txdv>ja
12:49:28  * quijotejoined
12:53:56  * quijotequit (Ping timeout: 250 seconds)
13:03:48  <tpar>so, another newbie/silly question if anyone cares to humour me :-)
13:03:57  <tpar>the fine manual's Design Overview section notes: "
13:03:59  <tpar>libuv uses a thread pool to make asynchronous file I/O operations possible, but network I/O is always performed in a single thread, each loop’s thread."
13:04:12  <tpar>I wonder what is the reason for this design decision?
13:04:39  <tpar>specifically, why are network IO operations single threaded rather than handled asynchronously by the thread pool?
13:05:21  * andrehjrjoined
13:16:07  * AvianFlujoined
13:17:31  * daviquit (Ping timeout: 244 seconds)
13:26:32  <txdv>tpar: the OS handles the paralellity
13:28:09  <nathan7>tpar: the thread pool is a workaround
13:28:27  <nathan7>tpar: because pretty much no OSes provide real asynchronous file I/O
13:29:01  <txdv>windows does
13:34:32  <zhpeng>excuse me, aio_read/write are also NOT real asynchronous file I/O?
13:39:54  * tarrudaquit (Quit: WeeChat 1.0.1)
13:40:52  * tarrudajoined
13:46:55  <tpar>^ hum, but e.g. send can block if the message is too large to fit into the socket's send buffer, right?
13:47:23  <tpar>in this case would I be best advised to farm off the actual I/O calls to the thread pool myself?
13:48:27  <tpar>(thanks for the answers, btw)
13:50:20  * quijotejoined
13:54:37  * quijotequit (Ping timeout: 240 seconds)
14:23:49  * andrehjrquit (Quit: Computer has gone to sleep.)
14:31:08  * [spoiler]quit (Quit: Leaving)
14:33:12  <nathan7>txdv: we do not speak of windows
14:34:39  <nathan7>zhpeng: Yes, it bypasses the buffer cache, and performs disk IO directly
14:34:52  <nathan7>zhpeng: which is an excellent way to ruin your performance
14:37:09  <nathan7>zhpeng: it's probably doing O_DIRECT style stuff
14:37:30  <nathan7>zhpeng: and aio_read/aio_write are implemented by glibc, spawning a thread for every read and write
14:37:44  <nathan7>zhpeng: so no, they're not "real asynchronous file I/O"
14:38:55  <zhpeng>nathan7: thank you, i see.
14:39:01  * zhpengquit (Quit: 离开)
14:40:16  <nathan7>god, I hate operating systems
14:50:59  * quijotejoined
14:55:49  * quijotequit (Ping timeout: 258 seconds)
15:11:59  * SergeiRNDquit (Quit: Leaving.)
15:29:36  * lanceballquit (Changing host)
15:29:36  * lanceballjoined
15:29:44  * quijotejoined
15:36:57  * tparquit (Quit: leaving)
15:46:58  * a_lequit (Remote host closed the connection)
15:54:12  * tarrudaquit (Ping timeout: 250 seconds)
16:02:10  * andrehjrjoined
16:11:07  * a_lejoined
16:20:27  * Fishrock123joined
16:20:40  * iarnajoined
16:20:59  * quijotequit (Ping timeout: 265 seconds)
16:21:17  * Fishrock123quit (Client Quit)
16:31:44  * iarnaquit (Remote host closed the connection)
16:33:24  * a_lequit (Remote host closed the connection)
16:40:51  * a_lejoined
16:44:26  * a_lequit (Remote host closed the connection)
16:45:22  * a_lejoined
17:04:52  * SergeiRNDjoined
17:13:06  * SergeiRNDquit (Quit: Leaving.)
17:18:25  * quijotejoined
17:22:37  * quijotequit (Ping timeout: 240 seconds)
17:23:04  * chris_99quit (Remote host closed the connection)
17:48:39  * quijotejoined
17:53:12  * quijotequit (Ping timeout: 245 seconds)
17:58:30  * iarnajoined
18:06:24  * dsantiagojoined
18:17:15  * jgijoined
18:18:44  <srl295>jgi: ping
18:19:10  <jgi>srl295: hey! Basically I just wanted to let you know that I was off until January 4th
18:19:23  <jgi>srl295: but i commented in the GH issue, and I saw you responded
18:31:18  <srl295>jgi yes and pisceasaurus (sp)
18:31:27  <jgi>srl295: rigjt
18:31:29  <jgi>right
18:33:10  <srl295>With excellent points, but the Q is how to move things along
18:44:53  * iarnaquit (Remote host closed the connection)
18:49:03  * iarnajoined
18:49:24  * quijotejoined
18:51:31  * tarrudajoined
18:52:17  <jgi>srl295: yes, I thought that there had been an agreement on the design before I started looking at it, but I wasn’t part of these discussions, so I can’t really comment on that.
18:53:17  * iarnaquit (Remote host closed the connection)
18:53:37  * quijotequit (Ping timeout: 245 seconds)
18:56:26  * iarnajoined
18:57:58  <jgi>srl295: if it doesn’t move forward when I’m off, I’ll pick it up as soon as I’m back.
18:59:21  * jgiquit (Quit: jgi)
19:10:53  * tarrudaquit (Ping timeout: 240 seconds)
19:15:16  * iarnaquit (Remote host closed the connection)
19:20:27  * iarnajoined
19:25:08  * iarnaquit (Ping timeout: 264 seconds)
19:34:45  * deleishajoined
19:35:21  * deleisha_joined
19:35:25  * iarnajoined
19:36:09  * iarnaquit (Remote host closed the connection)
19:38:47  * deleishaquit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com ))
19:44:50  * a_lequit (Read error: Connection reset by peer)
19:45:22  * a_lejoined
19:46:14  <srl295>jgi thanks!
19:48:54  * SergeiRNDjoined
19:50:20  * quijotejoined
19:53:21  * dsantiagoquit (Quit: Computer has gone to sleep.)
19:54:17  * quijotequit (Ping timeout: 240 seconds)
19:58:03  * iarnajoined
19:59:23  * iarnaquit (Remote host closed the connection)
20:01:42  * iarnajoined
20:01:57  * iarnaquit (Remote host closed the connection)
20:07:25  * chris_99joined
20:08:17  * iarnajoined
20:08:57  * iarnaquit (Read error: Connection reset by peer)
20:13:53  * iarnajoined
20:17:21  * iarnaquit (Remote host closed the connection)
20:25:19  * AvianFluquit (Ping timeout: 244 seconds)
20:28:22  * iarnajoined
20:42:27  <srl295>octetcloud tjfontaine jgi: just for the record, vcbuild rebuilds config.gypi and now icu_config.gypi - I don't think I made things any worse.
20:44:16  * SergeiRNDquit (Quit: Leaving.)
21:15:57  * dsantiagojoined
21:28:46  * tarrudajoined
21:29:53  * Ralithquit (Ping timeout: 240 seconds)
21:51:39  * quijotejoined
21:56:27  * quijotequit (Ping timeout: 244 seconds)
22:06:38  * warehouse13joined
22:07:44  * Left_Turnquit (Ping timeout: 250 seconds)
22:08:43  * Ralithjoined
22:15:46  * deleisha_quit (Ping timeout: 246 seconds)
22:17:26  * Ralithquit (Ping timeout: 244 seconds)
22:20:37  * FROGGS[mobile]quit (Remote host closed the connection)
22:52:23  * quijotejoined
22:57:17  * quijotequit (Ping timeout: 258 seconds)
23:02:19  * avalanche123joined
23:06:41  * avalanche123quit (Client Quit)
23:14:39  * chris_99quit (Quit: Ex-Chat)
23:27:17  * tarrudaquit (Ping timeout: 240 seconds)
23:31:13  * seishunquit (Ping timeout: 272 seconds)
23:53:09  * quijotejoined
23:57:48  * quijotequit (Ping timeout: 250 seconds)