00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:13  * ircretaryjoined
00:00:25  * brsonquit (Quit: leaving)
00:12:08  * brsonjoined
00:12:37  * brsonquit (Client Quit)
00:41:25  * chris_99quit (Quit: Ex-Chat)
00:43:23  * avalanche123quit (Ping timeout: 240 seconds)
00:43:55  * avalanche123joined
00:46:34  * iarnaquit (Read error: Connection reset by peer)
00:47:10  * iarnajoined
00:52:45  * thlorenzjoined
00:57:54  * thlorenzquit (Ping timeout: 256 seconds)
00:59:02  * octetcloudquit (Ping timeout: 256 seconds)
00:59:33  * octetcloudjoined
01:04:06  * AlexisMochajoined
01:10:37  * thlorenzjoined
01:15:51  * wolfeidauquit (Remote host closed the connection)
01:17:25  * abraxas_joined
01:19:56  * kriskowalquit (Quit: kriskowal)
01:21:34  * thlorenzquit (Remote host closed the connection)
01:21:52  * abraxas_quit (Ping timeout: 258 seconds)
01:26:22  * bradleymeckquit (Quit: bradleymeck)
01:28:03  * abraxas_joined
01:30:39  * iarnaquit (Remote host closed the connection)
01:34:44  * kriskowaljoined
01:46:51  * Ralithquit (Ping timeout: 255 seconds)
01:47:10  * iarnajoined
01:47:16  * dap_1quit (Quit: Leaving.)
01:50:49  * avalanche123quit (Remote host closed the connection)
01:55:56  * thlorenzjoined
02:04:23  * kriskowalquit (Quit: kriskowal)
02:11:46  * iarnaquit (Remote host closed the connection)
02:12:01  * Ralithjoined
02:53:44  * jgiquit (Quit: jgi)
02:59:47  * thlorenzquit (Remote host closed the connection)
03:00:29  * thlorenzjoined
03:01:19  * thlorenz_joined
03:03:26  * thlorenz_quit (Remote host closed the connection)
03:04:53  * thlorenzquit (Ping timeout: 240 seconds)
03:24:17  * Fishrock123quit (Quit: Leaving...)
03:42:00  * AlexisMochaquit (Ping timeout: 244 seconds)
03:50:18  * inolenquit (Read error: Connection reset by peer)
04:04:07  * thlorenzjoined
04:09:29  * thlorenzquit (Ping timeout: 265 seconds)
04:19:49  * Left_Turnquit (Remote host closed the connection)
04:37:53  * bradleymeckjoined
04:51:38  * avalanche123joined
04:56:02  * avalanche123quit (Ping timeout: 250 seconds)
05:12:36  * iarnajoined
05:17:00  * iarnaquit (Ping timeout: 255 seconds)
05:49:41  * importantshockquit (Remote host closed the connection)
05:50:14  * importantshockjoined
05:54:17  * importantshockquit (Ping timeout: 240 seconds)
06:03:44  * bradleymeckquit (Quit: bradleymeck)
06:06:04  * rmgquit (Remote host closed the connection)
06:35:28  * kellabytequit (Quit: Connection closed for inactivity)
06:35:33  * janjongboomjoined
06:35:37  * seishunjoined
06:42:11  * bajtosjoined
06:46:37  * octetcloudquit (Ping timeout: 240 seconds)
07:06:36  * rmgjoined
07:11:32  * rmgquit (Ping timeout: 245 seconds)
07:23:34  * rendarjoined
07:30:39  * seishunquit (Ping timeout: 255 seconds)
07:41:52  * thlorenzjoined
07:44:11  * bajtosquit (Quit: bajtos)
07:46:26  * bajtosjoined
07:46:35  * avalanche123joined
07:46:53  * thlorenzquit (Ping timeout: 264 seconds)
08:11:55  * avalanche123quit (Remote host closed the connection)
08:50:51  * a3fjoined
08:55:28  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:58:06  * SergeiRNDjoined
09:10:08  * janjongboomjoined
09:12:16  * avalanche123joined
09:16:48  * avalanche123quit (Ping timeout: 244 seconds)
09:27:09  * AlexisMochajoined
09:31:14  * thlorenzjoined
09:35:36  * thlorenzquit (Ping timeout: 258 seconds)
09:39:49  * janjongboomquit (Ping timeout: 258 seconds)
09:41:15  * janjongboomjoined
09:53:17  * janjongboomquit (Ping timeout: 264 seconds)
09:54:08  * janjongboomjoined
10:28:41  * chris_99joined
10:43:17  * kellabytejoined
10:44:23  * a3fquit (Remote host closed the connection)
10:54:29  * Left_Turnjoined
10:55:46  * abraxas_quit (Remote host closed the connection)
10:56:37  * iarnajoined
10:57:08  * chris_99quit (Quit: Ex-Chat)
11:02:47  * SergeiRNDquit (Quit: Leaving.)
11:05:10  * tarrudajoined
11:11:14  * iarnaquit (Read error: Connection reset by peer)
11:11:47  * iarnajoined
11:16:58  * importantshockjoined
11:19:51  * thlorenzjoined
11:24:22  * thlorenzquit (Ping timeout: 240 seconds)
11:25:22  * jas-joined
11:25:47  * jas-quit (Remote host closed the connection)
11:32:45  * SergeiRNDjoined
11:44:44  * chris_99joined
11:55:45  * jas-joined
11:57:54  * importantshockquit (Remote host closed the connection)
12:08:46  * jas-quit (Remote host closed the connection)
12:26:56  * AvianFluquit (Ping timeout: 244 seconds)
12:39:51  * janjongboomquit (Ping timeout: 244 seconds)
12:41:16  * janjongboomjoined
12:44:47  * abraxas_joined
12:45:29  * kellabytequit (Quit: Connection closed for inactivity)
12:49:57  * abraxas_quit (Ping timeout: 258 seconds)
13:08:37  * thlorenzjoined
13:09:15  * kellabytejoined
13:13:01  * thlorenzquit (Ping timeout: 255 seconds)
13:23:14  * thlorenzjoined
13:25:46  * thlorenzquit (Remote host closed the connection)
13:26:17  * thlorenzjoined
13:30:37  * thlorenzquit (Ping timeout: 240 seconds)
13:40:17  * bradleymeckjoined
13:41:55  * tarrudaquit (Quit: WeeChat 0.4.2)
13:43:27  * tarrudajoined
13:52:45  * thlorenzjoined
14:10:50  * rphillipsquit (Ping timeout: 258 seconds)
14:11:04  * janjongboomquit (Ping timeout: 255 seconds)
14:11:57  * janjongboomjoined
14:13:03  * rphillipsjoined
14:15:35  * Fishrock123joined
14:24:12  * avalanche123joined
14:29:04  * avalanche123quit (Ping timeout: 255 seconds)
14:34:11  * abraxas_joined
14:38:47  * abraxas_quit (Ping timeout: 265 seconds)
14:49:02  * a_lejoined
15:01:35  * saghul|afkchanged nick to saghul
15:07:04  * dsantiagoquit (Quit: Computer has gone to sleep.)
15:11:47  * janjongboomquit (Ping timeout: 258 seconds)
15:12:29  * janjongboomjoined
15:14:17  * SergeiRNDquit (Quit: Leaving.)
15:28:45  * a_le_joined
15:29:06  * a_lequit (Read error: Connection reset by peer)
15:50:08  * a_le_quit (Ping timeout: 255 seconds)
15:53:03  * thlorenzquit
15:53:08  * rmgjoined
15:53:43  * a_lejoined
15:54:12  * thlorenzjoined
15:55:06  * janjongboomquit (Ping timeout: 255 seconds)
15:56:08  * janjongboomjoined
15:58:05  * rmgquit (Ping timeout: 264 seconds)
16:00:18  * bajtosquit (Quit: bajtos)
16:03:54  <creationix>saghul: since we’re doing RFCs for libuv now, has there been any discussion around adding memory mapping to the fs operations? The lack of mem-mapping in node is one of the largest things making it hard for my git implementation to compete with Linus’ code.
16:03:56  * thlorenzquit
16:05:29  <saghul>creationix: there has been no such discussion
16:05:29  * thlorenzjoined
16:06:07  <saghul>creationix: I plan to work on some document explaining the RFC process tonight, will poke you when ready so you can propose your own!
16:06:45  <creationix>cool. I don’t even fully understand mem-mapping since I’ve never used it personally, but it seems like something that could be super useful.
16:07:13  <bradleymeck>creationix: basically they load a file into
16:07:19  <bradleymeck>ram as shared memory
16:07:43  <bradleymeck>file doesn't necessarily have to be on disk (for *nix) but it has a fd
16:07:47  <creationix>right, but multiple processes can access the same file to implement shared memory across processes I think
16:07:56  <bradleymeck>yes
16:08:04  <bradleymeck>but you will want to add locking structures
16:08:20  <creationix>I was looking at lmdm last night and saw how they used it to make their embedded database safe for multi-process systems
16:09:05  <bradleymeck>creationix: http://www.linuxjournal.com/content/lock-free-multi-producer-multi-consumer-queue-ring-buffer might give you some info, but you want a lockless ring for requests
16:09:26  <bradleymeck>requests generally being to lock a table
16:09:30  <bradleymeck>or something
16:10:38  <creationix>now my question is would exposing mutable shared ram to a scripting language make sense?
16:10:47  <creationix>I guess it would be something like a node buffer?
16:10:50  <bradleymeck>unlikely
16:10:56  <bradleymeck>a shared hash table sure
16:11:36  <bradleymeck>but if you can hold onto a piece of shared ram and mutate it :(
16:11:55  <bradleymeck>same problem as mutating fs buffer in node when they get reused
16:17:08  * thlorenzquit
16:17:43  * thlorenzjoined
16:21:17  <creationix>bradleymeck: or for the non-shared case where I just want to do lots of random reads and writes to a file on disk. Mem-mapping is often much faster than fs syscalls for certain workloads.
16:21:34  <bradleymeck>yes
16:21:45  <bradleymeck>but you need to sync to disk once you are done
16:21:49  <creationix>but I don’t know the exact semantics. I assume reading a piece of the file that’s not in ram already would block my process right?
16:21:58  <creationix>so it could hurt the event-loop model
16:22:32  <creationix>though I guess we could have async versions of read and write that go through the thread pool
16:22:58  <creationix>read and sync
16:23:04  * abraxas_joined
16:23:06  <creationix>write is probably non-blocking always
16:23:29  <bradleymeck>it is loaded into memory and can be swapped just like most things
16:23:42  <bradleymeck>you could mprotect to force it to stay in ram
16:28:05  * abraxas_quit (Ping timeout: 264 seconds)
16:31:46  * AlexisMochaquit (Ping timeout: 256 seconds)
16:37:30  <bradleymeck>creationix: I guess the key thing is that you will need msync() setup as well as mmap() to flush your changes to the fs rather than just mutating it in ram
16:38:10  * chris_99quit (Quit: Ex-Chat)
16:38:20  <bradleymeck>s/ram/memory/
16:39:02  <creationix>well, depends on the use case. For writing a database I’d only want to sync to disk when users of my API want some form of assurance it’s actually written
16:39:56  <bradleymeck>yea mysync would need to be exposed somehow
16:41:09  <creationix>hmm, looks like the current node binding and ben’s original only exposed mmap https://github.com/geocar/mmap
16:41:30  * janjongboomquit (Ping timeout: 250 seconds)
16:41:44  <creationix>and sync
16:42:45  * janjongboomjoined
16:45:03  * bajtosjoined
16:45:22  * bradleymeckquit (Quit: bradleymeck)
16:54:18  * seishunjoined
16:55:45  * octetcloudjoined
16:59:54  * rmgjoined
17:15:43  * bradleymeckjoined
17:15:57  * SergeiRNDjoined
17:22:27  * AvianFlujoined
17:25:39  * pbunnyquit (Ping timeout: 245 seconds)
17:26:27  * lanceballchanged nick to lance|afk
17:27:24  * AvianFluquit (Quit: Leaving)
17:28:19  * AvianFlujoined
17:29:02  * avalanche123joined
17:31:38  * chris_99joined
17:33:32  * avalanche123quit (Ping timeout: 256 seconds)
17:39:25  * SergeiRNDquit (Quit: Leaving.)
17:46:22  * AlexisMochajoined
17:47:24  * jgijoined
17:48:02  <indutny>creationix: http://github.com/indutny/mmap.js
17:48:27  <indutny>I'm up to improving it if you want me to
17:48:49  <indutny>the good thing about it is that it is capable of allocating executable memory
17:49:11  <creationix>you write a jit that uses this right?
17:54:49  * bradleymeckquit (Quit: bradleymeck)
17:56:28  * janjongboomquit (Ping timeout: 250 seconds)
17:57:36  * bradleymeckjoined
17:57:37  * janjongboomjoined
18:01:59  <indutny>creationix: yep
18:02:54  <creationix>indutny: how portable is the assembly generated? Is it just x64?
18:03:02  <indutny>just x64 for now
18:04:30  <creationix>have you looked at how dynasm works? I think it’s usable independent of luajit
18:06:25  <creationix>I’m thinking about using it to write a jack interpreter that’s actually fast enough to usable
18:10:59  * iarnaquit (Remote host closed the connection)
18:11:50  * abraxas_joined
18:16:54  * abraxas_quit (Ping timeout: 264 seconds)
18:17:04  <indutny>creationix: not really
18:17:31  <indutny>creationix: guess it is quite cool, since luajit is using it
18:18:31  <creationix>though he did stop using it for the jit part in luajit 2.0 (he wanted more direct control)
18:18:39  <creationix>but it seems to work great for the assembly interpreter
18:24:16  * kriskowaljoined
18:26:30  * janjongboomquit (Ping timeout: 264 seconds)
18:27:13  * janjongboomjoined
18:35:37  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:40:22  * dap_joined
18:44:06  * octetcloudquit (Ping timeout: 244 seconds)
18:49:12  * thlorenzquit (Remote host closed the connection)
18:59:47  <a_le>pquerna: YT?
19:01:47  <pquerna>a_le: 50% here
19:02:06  <a_le>:)
19:03:11  <a_le>what exactly is missing from Selene?
19:03:37  * thlorenzjoined
19:03:51  <a_le>and how different is it from botan, aside from the fact that it offers a C interface instead of a C++ one?
19:04:09  * janjongboomjoined
19:04:17  * SergeiRNDjoined
19:04:19  <a_le>pquerna: ^
19:05:40  * thlorenzquit (Remote host closed the connection)
19:06:23  * janjongboomquit (Client Quit)
19:13:41  * SergeiRNDquit (Quit: Leaving.)
19:17:45  * octetcloudjoined
19:19:14  * inolenjoined
19:20:09  * am11joined
19:20:48  * bajtosquit (Quit: bajtos)
19:23:46  * thlorenzjoined
19:24:28  * importantshockjoined
19:25:18  * rendarquit (Ping timeout: 250 seconds)
19:31:22  * importantshockquit (Remote host closed the connection)
19:31:31  * importantshockjoined
19:32:10  * rendarjoined
19:37:57  * importantshockquit (Remote host closed the connection)
19:41:20  * avalanche123joined
19:42:05  * thlorenz_joined
19:42:17  * petka_joined
19:46:46  * thlorenz_quit (Ping timeout: 255 seconds)
19:47:13  * bradleymeckquit (Quit: bradleymeck)
19:49:05  * chris_99quit (Ping timeout: 265 seconds)
19:51:14  * petka_quit (Ping timeout: 258 seconds)
19:52:46  * petka_joined
19:53:19  <trevnorris>saghul: ping
19:55:17  * importantshockjoined
19:58:39  <trevnorris>saghul: nm
20:00:36  * abraxas_joined
20:00:51  * piscisaureusjoined
20:01:49  * thlorenzquit (Remote host closed the connection)
20:02:32  * chris_99joined
20:02:49  * thlorenz_joined
20:04:45  * importantshockquit (Remote host closed the connection)
20:05:12  * importantshockjoined
20:05:31  * abraxas_quit (Ping timeout: 265 seconds)
20:05:34  * bradleymeckjoined
20:09:17  * importantshockquit (Ping timeout: 240 seconds)
20:09:27  <MI6>joyent/node: Saúl Ibarra Corretgé v0.12 * 9d9ed61 : deps: update libuv to 1.0.0 - http://git.io/XQEnpA
20:10:55  * importantshockjoined
20:17:59  <MI6>joyent/node: Nathan Woltman v0.12 * e0a0e91 : path: refactor normalizeArray() - http://git.io/Gy7oHQ
20:20:38  * importantshockquit (Remote host closed the connection)
20:21:18  <piscisaureus>saghul: I think the fix you did for the "valgrind child process issue" warrants a 1.0.1 release
20:21:25  <piscisaureus>saghul: we don't want memory corruption to happen
20:23:26  * importan_joined
20:33:47  <MI6>joyent/node: Trevor Norris v0.10 * 0d05123 : timers: fix unref() memory leak - http://git.io/I6vlXg
20:35:45  <trevnorris>piscisaureus: not 100% sure what you're talking about, but sounds like a +1 from me. I use valgrind w/ libuv a lot.
20:38:17  <piscisaureus>saghul: I made a release
20:40:42  <MI6>joyent/node: Vladimir Kurchatkin v0.12 * bf3e0f4 : smalloc: don't allow to dispose typed arrays - http://git.io/wS7IuQ
20:41:25  <piscisaureus>trevnorris: the issue was caught with valgrind, was actually more serious than that
20:41:33  <trevnorris>ah, okay.
20:41:40  <piscisaureus>trevnorris: saghul had already fixed it, I just released 1.0.1
20:41:58  <trevnorris>piscisaureus: can you PR an upgrade to node?
20:42:51  <saghul>ahoi
20:42:55  <saghul>sorry, was afk
20:43:04  <saghul>thanks for making the release piscisaureus!
20:43:14  <piscisaureus>easy as always
20:43:27  <piscisaureus>saghul: btw, I noticed that the release tool no longer does "Now working on xxx"
20:43:34  <piscisaureus>saghul: you decided that's pointless?
20:43:35  <saghul>if you want I can make the node PR
20:43:59  <piscisaureus>saghul: if you want to I am the merrier
20:44:08  <saghul>piscisaureus: kidn of, now we don't know if the next release will be 1.0.2 or 1.1.0, depends
20:44:20  <saghul>piscisaureus: xD
20:44:32  <saghul>will do after this LEP thing I'm writing
20:52:44  <trevnorris>tjfontaine: hey, the PR is pretty much there. i'm screwing with a few tidbits, but they're in an additional commit that can be dropped.
20:53:44  <MI6>joyent/libuv: piscisaureus created branch moved - http://git.io/H9DGaQ
20:59:37  * piscisaureusquit (Ping timeout: 240 seconds)
21:12:53  * thlorenzjoined
21:17:22  * thlorenzquit (Ping timeout: 256 seconds)
21:22:45  * AlexisMochaquit (Ping timeout: 272 seconds)
21:29:37  * jgiquit (Quit: jgi)
21:39:33  * piscisaureusjoined
21:41:59  * bradleymeckquit (Quit: bradleymeck)
21:53:54  <saghul>trevnorris: here you go https://github.com/joyent/node/pull/8785
21:54:08  <saghul>i'm off, g'night everyone!
21:54:51  <trevnorris>saghul: awesome. thanks.
22:00:58  * avalanche123quit (Remote host closed the connection)
22:01:30  * avalanche123joined
22:05:37  * avalanche123quit (Ping timeout: 240 seconds)
22:05:50  * jgijoined
22:14:13  * inolenquit (Ping timeout: 258 seconds)
22:15:29  * jgiquit (Quit: jgi)
22:16:20  * rendarquit
22:19:08  * txdvquit (Ping timeout: 256 seconds)
22:20:33  * importan_quit (Remote host closed the connection)
22:21:01  * importantshockjoined
22:26:05  * importantshockquit (Ping timeout: 272 seconds)
22:26:31  * jgijoined
22:30:49  * avalanche123joined
22:33:25  * bradleymeckjoined
22:44:17  * seishunquit (Ping timeout: 264 seconds)
22:47:21  * txdvjoined
22:51:02  * janjongboomjoined
22:55:08  * c4milojoined
22:55:11  * c4miloquit (Remote host closed the connection)
22:57:26  * bradleymeckquit (Quit: bradleymeck)
23:06:43  * c4milojoined
23:14:59  * bradleymeckjoined
23:15:40  <a_le>i have an idle callback and that is causing my thread to grab 100% CPU
23:16:03  <a_le>should I rather implement it as a timer that repeats often?
23:17:28  <piscisaureus>a_le: a timer would probably be better. With an idle handle you'll use 100% cpu indeed.
23:17:39  <a_le>piscisaureus: sigh
23:18:04  <piscisaureus>a_le: what else did you expect?
23:18:33  <a_le>i expected some magic :D
23:18:59  <piscisaureus>a_le: we can't have nice things. It's the human condition.
23:19:34  <a_le>by magic i meant, run when we really are NOT busy at all, like after a few hundred ms of idleness
23:19:42  * bradleymeckquit (Quit: bradleymeck)
23:19:55  <a_le>as in: each time we are idle, but not more than once every -say- 200ms
23:20:04  <a_le>not back to back
23:20:17  * octetcloudquit (Ping timeout: 245 seconds)
23:20:31  <piscisaureus>a_le: no, the idle callback runs continuously.
23:20:50  <piscisaureus>a_le: if you want this, do this: create a 200ms interval timer that calls your callback
23:20:55  * janjongboomquit (Ping timeout: 258 seconds)
23:21:15  <piscisaureus>a_le: have a uv_check handle and call uv_timer_reset(timer) in the callback
23:21:36  * janjongboomjoined
23:21:44  <piscisaureus>a_le: that ensures that your timer is called after 200ms of idle-ness
23:22:49  <piscisaureus>you should probably uv_unref both handles
23:23:26  <a_le>piscisaureus: uv_check callback is invoked after we return from blocking, right?
23:23:42  <piscisaureus>a_le: yes, but before timer are run
23:23:51  * qard_joined
23:25:24  <a_le>1 sec, sorry
23:25:25  <piscisaureus>a_le: actually, so then the timer callback may not be run even if the loop was blocked for 200ms... hmm...
23:25:37  * janjongboomquit (Ping timeout: 240 seconds)
23:25:59  <piscisaureus>a_le: right, it should probably be a prepare handle and not a check handle
23:26:09  * octetcloudjoined
23:28:27  * janjongboomjoined
23:29:19  <a_le>piscisaureus: I am only aware of uv_timer_\(init\|start\|stop\|again\|set_repeat\) and uv_close
23:30:06  <piscisaureus>a_le: ah, it's uv_timer_again()
23:30:17  <piscisaureus>a_le: sorry I misremembered the function name
23:32:53  * octetcloudquit (Ping timeout: 264 seconds)
23:33:51  <a_le>so my prepare callback should be also the timer callback?
23:34:26  * AlexisMochajoined
23:34:36  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:38:28  * abraxas_joined
23:38:40  <piscisaureus>al_le: no they have separate callbacks
23:39:01  <piscisaureus>al_le: the prepare callback just does uv_timer_again on the timer handle
23:39:18  <piscisaureus>al_le: the timer callback does the actual work that you wanted to do in the idle callback
23:43:18  * abraxas_quit (Ping timeout: 264 seconds)
23:43:34  <a_le>piscisaureus: if there has been some other event, i want to run my idle business once
23:44:02  <piscisaureus>hmm
23:44:25  <piscisaureus>a_le: then probably you want to do nothing in the timer callback and run your idle business in the prepare callback too?
23:45:00  <a_le>and reschedule the timer each time the prepare happens?
23:45:27  <piscisaureus>a_le: yeah
23:45:35  <a_le>piscisaureus: why shouldn't i use a check again?
23:46:05  <a_le>actually I could probably just run my stuff in a check callback
23:46:25  <piscisaureus>a_le: well I guess it doesn't matter now any more. The reason was that otherwise the timer callback would never run, but that's not an issue any more because it's empty anyways.
23:46:28  <a_le>i want for example to be able to detect if some reference counting of mine has gone down to zero upon running any callback
23:46:45  <piscisaureus>al_le: so you now only need the timer so the loop never blocks for more than 200ms
23:47:04  <a_le>i am thinking that probably i don't care about waking up every 200ms
23:47:38  <piscisaureus>if you just want to wake up every loop iteration use a check or a prepare
23:47:41  <piscisaureus>it's not that hard
23:47:49  <a_le>piscisaureus: why don't i see the check callbacks here in the first code snippet? http://nikhilm.github.io/uvbook/eventloops.html
23:48:30  <piscisaureus>a_le: yeah that's an oversight. the book is incorrect
23:49:01  <piscisaureus>uv_check runs every iteration after blocking.
23:49:02  <a_le>actually it's identical to the real code
23:49:19  <a_le>maybe it's within uv__run_pending() ?
23:50:07  <a_le>piscisaureus: as in: the check callback is always queued at the end of the queue?
23:50:27  <piscisaureus>a_le: https://github.com/libuv/libuv/blob/master/src/unix/core.c#L324
23:50:41  <a_le>oh it's down below
23:50:49  <piscisaureus>prepare is always right before epoll(), kqueue() etc, check is always after
23:50:55  <piscisaureus>"end of the queue" is kinda unclear
23:51:24  <a_le>so the callbacks are always queued for the next loop to pick up
23:51:31  <a_le>and then the loop blocks after prepare
23:51:35  <a_le>and then it runs check
23:51:44  <a_le>and then it loops around and invokes all relevant callbacks?
23:52:17  <piscisaureus>a_le: there isn't really a callback queue and
23:52:33  <piscisaureus>all the check handles are just invoked exactly once after blocking ... that's all
23:52:43  <a_le>what is uv__run_pending doing?
23:53:56  <piscisaureus>a_le: that iterates over all the file descriptors that epoll/kqueue (or whatever gets called by uv__io_poll) returned
23:54:07  <piscisaureus>a_le: so callbacks do get called by it
23:54:28  <a_le>oh so the callbacks for sockets and disk I/O only get invoked at the next loop iteration?
23:54:33  <piscisaureus>a_le: what I am trying to say is that libuv doesn't so much "schedule" individual callbacks
23:54:38  <a_le>so, potentially after the check callbacks?
23:54:55  <piscisaureus>a_le: it just calls the callback at places
23:55:11  <a_le>piscisaureus: i guess more than asking questions i should explain what exactly i am worried about
23:55:12  <piscisaureus>a_le: yeah
23:55:19  * inolenjoined
23:56:14  <a_le>piscisaureus: my worry is... if i keep on checking every 200ms, it will work for sure. but i would like not to do so because it's not very clean. if i check in the check callback, and the callbacks haven't been invoked yet, then I will not be able to check again until the next event has happened.
23:56:39  <piscisaureus>a_le: true, so you use a prepare callback?
23:57:10  * thlorenz_quit (Remote host closed the connection)
23:58:43  * thlorenzjoined
23:58:43  <MI6>joyent/node: Saúl Ibarra Corretgé v0.12 * 0308ad2 : crypto: cast uv_thread_t to unsigned long (+1 more commits) - http://git.io/O9ZVxw
23:58:45  <a_le>piscisaureus: it would run only once right?
23:58:52  * c4miloquit (Remote host closed the connection)
23:59:00  <a_le>piscisaureus: yes that seems to make sense
23:59:11  <a_le>it would run just once and right after the last event
23:59:17  * chris_99quit (Quit: Ex-Chat)