10:37:52  * thealphanerdquit (Quit: farewell for now)
10:38:23  * thealphanerdjoined
12:45:17  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
13:12:49  * rendarjoined
13:18:09  * avalanche123joined
13:22:49  * avalanche123quit (Ping timeout: 252 seconds)
13:53:29  * etnbrdjoined
13:53:41  * saghuljoined
14:23:43  * rgrinbergjoined
15:17:05  * jharkjoined
15:35:23  <jhark>Hi. Am I correct in thinking that the synchronous file system operations are all thread-safe? Looks that way on first inspection of the source. I couldn't find any documentation to this effect, so I assume that even if it's true it's Subject To Change.
15:44:46  <rendar>jhark: i guess you must run all fs operations from the same thread
15:45:01  <rendar>since libuv is not thread safe
15:45:30  * seishunjoined
15:45:48  * joaocgreis_joined
15:45:49  * brycebaril_joined
15:46:31  <jhark>rendar: Sure, but looking at the source it seems that none of the functions touch global state (though I may have missed something), and they just call corresponding OS APIs (generally thread safe).
15:47:15  <rendar>jhark: not a global state but a state internal to the uv_stream_t structure for sure
15:47:19  <saghul>jhark they are thread safe
15:47:20  * mafintosh_joined
15:47:26  * zkat___joined
15:47:44  <rendar>saghul: oh really? but don't they touch internal uv_stream_t stuff?
15:47:54  <saghul>rendar not fs operations
15:48:02  * creation-joined
15:48:04  * paulfryzeljoined
15:48:15  <rendar>saghul: i see, so i can read/write to the same file from multiple threads?
15:48:17  <saghul>also that onyl applies to sync fs operations, which is what was asked
15:48:27  <jhark>saghul: thanks :)
15:48:34  <saghul>rendar using the sync API yes
15:48:43  <saghul>jhark pleasure!
15:48:49  <rendar>saghul: hmm, libuv has sync API?
15:48:55  * parshapquit (Ping timeout: 260 seconds)
15:48:56  * brycebarilquit (Ping timeout: 260 seconds)
15:48:56  * zkat__quit (Ping timeout: 260 seconds)
15:48:56  * jcrugzzquit (Ping timeout: 260 seconds)
15:48:59  * joaocgreisquit (Ping timeout: 260 seconds)
15:48:59  * paulfryz-quit (Ping timeout: 260 seconds)
15:48:59  * mafintoshquit (Ping timeout: 260 seconds)
15:49:00  * creationixquit (Ping timeout: 260 seconds)
15:49:00  * erikjquit (Ping timeout: 260 seconds)
15:49:01  * abruanesequit (Ping timeout: 260 seconds)
15:49:04  * creation-changed nick to creationix
15:49:04  <jhark>saghul: Is that something I can rely on in practise, or should I vet the source when updating :)
15:49:06  <saghul>rendar for fs operations, yes. Pass NULL as the callback
15:49:09  * abruanesejoined
15:49:29  * brycebaril_changed nick to brycebaril
15:49:30  <rendar>saghul: got it
15:49:31  <saghul>jhark you can rely on that.
15:49:37  <jhark>saghul: Oh, cool!
15:50:03  <saghul>note that we don't have seek operations exactly because of this. read operations could be run in parallel, that's why you must se the offset
15:50:08  * joaocgreis_changed nick to joaocgreis
15:50:29  <saghul>write operations have a global lock in OSX because it's not thread safe, but we take care of that
15:50:33  <jhark>saghul: Yeah, an API with an offset makes sense
15:50:40  <jhark>I noticed that too
15:50:45  * jcrugzzjoined
15:51:20  <jhark>Seems a bit surprising. Oh the joys of coping with the foibles of each platform.
15:51:34  * MLMquit (Ping timeout: 258 seconds)
15:52:01  * erikjjoined
15:52:01  * erikjquit (Changing host)
15:52:01  * erikjjoined
15:52:07  <saghul>that's the libuv spirit, we fix it so users don't have to :-)
15:52:14  <jhark><3
15:53:03  <jhark>I have done similar stuff for networking APIs in the past :P
15:54:26  <saghul>then you know the pain ;-0
15:55:35  * mafintosh_changed nick to mafintosh
15:55:53  <jhark>Sure do ;_; hehe. From a cursory glance it also looked like submitting async operations would also be thread-safe if the uv_loop_t queue operations were made thread-safe; is that right? I haven't really scrutinised it so far so I could be completely off-base there..
15:57:49  * parshapjoined
16:03:33  <rendar>saghul: write(2) is not thread safe in OSX? really?
16:04:05  <saghul>rendar in some cases no, it seems
16:04:18  <rendar>this is absurd, i think it violates also POSIX rules
16:04:30  * MLMjoined
16:04:43  <saghul>jhark kind of, none of the loop APIs are thread-safe except uv_async_send
16:05:17  <jhark>mmm; I know that they're definitely not safe as-is.
16:05:35  <saghul>rendar be that as it may, we have to deal with it :-S
16:05:49  <jhark>it was just that it seemed as though it might be relatively easy to make them safe
16:05:56  <saghul>jhark I mean, that's by design, we haven't tried to make them thread-safe
16:06:01  <jhark>which could be handy (for me at least)
16:06:07  <jhark>Yeah
16:06:50  <saghul>some operations might be easy-ish, others not so much, so the current approach is not to declare anything thread-safe
16:06:51  <jhark>I was considering making local changes to libuv, or adding my own thread safety external to libuv.
16:07:02  <jhark>Yeah, definitely fair
16:07:02  <saghul>with the exception of uv_async_Send
16:07:35  <saghul>jhark TBH I'm not sure you can make it completely thread-safe from the outside, if you keep the loop running, that is
16:09:09  <jhark>If the loop is on a dedicated thread, could other threads not just submit requests to it through some sort of queue? The dedicated thread is then the only thing that would call the uv_ API.
16:09:26  <rendar>jhark: you must change some libuv internal architecture to make it thread safe
16:09:48  <saghul>jhark yep, that would work
16:10:16  <jhark>Good good, thought so :)
16:10:30  <saghul>but you'll have to also implement the reverse, in order to process the data from the read callback, for example
16:10:41  <jhark>Yes, true
16:16:12  <jhark>saghul: Thanks for the help btw :)
16:16:48  <saghul>jhark No problemo!
16:20:35  * seishunquit (Ping timeout: 244 seconds)
16:23:52  * seishunjoined
16:54:37  * avalanche123joined
16:58:33  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
16:58:59  * avalanche123quit (Ping timeout: 252 seconds)
17:25:41  * seishunquit (Ping timeout: 244 seconds)
18:02:04  * seishunjoined
19:52:25  * seishunquit (Ping timeout: 244 seconds)
20:05:09  * Ralith__joined
20:10:13  * rgrinbergquit (*.net *.split)
20:10:13  * rendarquit (*.net *.split)
20:10:13  * Ralith_quit (*.net *.split)
20:10:13  * txdvquit (*.net *.split)
20:10:13  * bzozquit (*.net *.split)
20:10:13  * dagobert________quit (*.net *.split)
20:10:13  * kellabytequit (*.net *.split)
20:12:05  * bzozjoined
20:12:05  * dagobert________joined
20:12:05  * kellabytejoined
20:12:18  * txdvjoined
20:12:22  * dagobert________quit (Ping timeout: 243 seconds)
20:13:24  * rgrinbergjoined
20:24:53  * dagobert________joined
20:30:55  * avalanche123joined
20:33:03  * creationix_quit (Ping timeout: 240 seconds)
20:34:19  * rendarjoined
20:35:25  * avalanche123quit (Ping timeout: 265 seconds)
20:42:46  * tunniclm_joined
21:43:51  * creationix_joined
21:52:49  * avalanche123joined
21:58:13  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
22:08:01  * avalanche123quit (Remote host closed the connection)
22:08:27  * avalanche123joined
22:13:13  * avalanche123quit (Ping timeout: 255 seconds)
22:14:04  * avalanche123joined
22:26:09  * rgrinbergquit (Ping timeout: 250 seconds)
22:50:30  * daurnimatorquit (Remote host closed the connection)
23:16:23  * avalanche123quit (Remote host closed the connection)
23:32:40  * brsonjoined
23:43:20  * Jacob843quit (Remote host closed the connection)
23:46:39  * Jacob843joined