--- Log opened Tue Apr 01 00:00:34 2014
03:35 < TonyHe> Hi big brothers, i am the new beginner, i have a question about libuv: we know that when we will use fork in the *nix, there is always copy on write, so i want to know when we use Node cluster&child_process module to fork new process, is there any copy on write? or is there any force data copy?
03:36 < TonyHe> is there anyone?
03:39 < TonyHe> ????
05:30 < TonyHe> Hi big brothers, i am the new beginner, i have a question about libuv: we know that when we will use fork in the *nix, there is always copy on write, so i want to know when we use Node cluster&child_process module to fork new process, is there any copy on write? or is there any force data copy?
05:53 < groundwater> TonyHe: node always calls exec after fork. So I don't think you gain anything out of copy on write anyways. 
05:55 < TonyHe> so you mean there is not any Copy on write?
07:30 <@MI6> joyent/libuv: Maks Naumov master * 8722633 : windows: fix check in uv_tty_endgame() - http://git.io/-87P4g
08:45 < ninthwolf> is there any copy on write when we fork a new process?
08:47 < ninthwolf> is there anyone ?
08:51 < ninthwolf> come on....
09:01 < ninthwolf> when we use fork to create new process, is there any copy on write?
09:01 < ninthwolf> i mean if we use the *nix fork function, there is always copy on write so when we use the Node.js cluster module or child_process module to fork new process is there any copy on write?
11:31 < Sonderblade> i don't get libuv
11:31 < Sonderblade> it does everything for you? in a platform portable way? and asynchronously?
12:11 <@indutny> hey people
12:11 <@indutny> Sonderblade: yes
12:15 < saghul> Sonderblade: it can also be instructed to do ironing and the groceries! At an unbeatable price!
12:17 < Sonderblade> but can it do ssl?
12:22 < saghul> Sonderblade: nope, you need an adapter for that: https://www.youtube.com/watch?v=AIOqOxI0K_I
12:25 < Sonderblade> classic
12:39 < kkaefer_> is there a way to execute a function on a certain event loop from another thread, much like Darwin's dispatch_async?
12:40 < kkaefer_> ...or is the solution to use uv_async and a mutexed queue?
13:26 < kkaefer_> how can I remove a uv_async_t from a loop?
13:26 < kkaefer_> if I understand it correctly, it gets attached by calling uv_async_init()
13:26 < kkaefer_> but there doesn't seem to be a function to remove it?
13:27 < kkaefer_> (so that the loop count can drop to zero)
13:27 < kkaefer_> (err, ref count)
13:36 < kkaefer_> also, on http://nikhilm.github.io/uvbook/threads.html#inter-thread-communication, what does "mutexes and rwlocks DO NOT work inside a signal handler, whereas uv_async_send does." refer to?
13:37 < mmalecki> kkaefer_: uv_async_send is uv's cross-thread communication stuff
13:37 < mmalecki> well, cross-task really, since uv abstracts that into tasks
13:37 < kkaefer> I thought uv_queue_work is task based
13:38 < kkaefer> wheras uv_async is condition variables?
13:38 < mmalecki> oh, wait, let me back up here a bit and reread that, I might be confusing names
13:40 < mmalecki> I don't think uv_async_t is a condition variable
13:41 <@indutny> mmalecki: hey man :)
13:41 < mmalecki> indutny: herro
13:41 <@indutny> kkaefer: you could remove it via uv_close()
13:41 <@indutny> kkaefer: it is a uv_handle_t instance essentially
13:41 <@indutny> mmalecki: how are you?
13:42 < mmalecki> indutny: good, vacationing. in transit from Kuala Lumpur to Bali tonight
13:42 <@indutny> oh
13:42 <@indutny> going to see Marak? :)
13:42 <@indutny> haha
13:42 <@indutny> actually, I'm not sure where he's living
13:42 <@indutny> ah
13:42 < mmalecki> indutny: hahah, Marak is in Germany these days
13:42 <@indutny> he was in Goa, I think
13:42 <@indutny> oh really?
13:42 <@indutny> ok
13:42 < mmalecki> indutny: yeah, I was as surprised as you are
13:42 <@indutny> mmalecki: yeah
13:42 <@indutny> he is really silent nowadays
13:42 < mmalecki> doesn't seem like His Thing (tm)
13:43 <@indutny> I see
13:43 <@indutny> Bali is a really good choice
13:43 <@indutny> congrats :)
13:43 < mmalecki> thanks :)
13:43 <@indutny> I'm at Dubai right now
13:43 < mmalecki> oh, sweet! vacation too?
13:46 <@indutny> sort of, but not exactly :)
13:46 <@indutny> still trying to keep up with things
13:46 < mmalecki> oh yeah, I'm trying to do the same thing
13:46 <@indutny> mmalecki: http://www.ubergizmo.com/2014/03/voxer-3-0-for-ios-announced/
13:46 < mmalecki> it's...
13:46 < mmalecki> hard
13:47 < mmalecki> indutny: congrats!
13:47 <@indutny> thanks man
13:47 <@indutny> this means that we have quite huge spdy deployment
13:47 <@indutny> :)
13:47 < mmalecki> wow, nice! all with node-spdy?
13:47 <@indutny> yep, on server-side
13:48 <@indutny> on client-side our library
13:48 <@indutny> http://github.com/voxer/ispdy
13:48 < mmalecki> oh my, obj-c
13:49 < mmalecki> (I actually enjoy the language itself, it's just Apple APIs that are painful)
14:12 <@indutny> mmalecki: very:verbose:method:names
14:12 <@indutny> yeah
14:12 <@indutny> but there are some good parts
14:58 <@MI6> joyent/node: Ben Noordhuis master * 490d5ab : configure: make --v8-options switch more robust - http://git.io/EXCTow
15:07 <@MI6> joyent/libuv: saghul created branch udp-reuseaddr - http://git.io/tv7ItQ
16:09 < ninthwolf> is there any one?
16:11 < groundwater> ninthwolf: there is no copy on write, because you're calling exec, not just fork
16:11 < groundwater> that is my understanding
16:11 < rendar> ninthwolf: what is your question?
16:12 < ninthwolf> i want to know when we use cluster&child_process module to fork process, is there any copy on write?
16:14 < groundwater> ninthwolf: we've answered this question twice now
16:14 < ninthwolf> you mean in the *nix platform?
16:17 < ninthwolf> so that means when we use Node's cluster&child_process module to fork new process, there is not any copy on write for data section or code section it is quite a new process?
16:28 < nankonami> i just found a good irc client
17:36 < trevnorris> morning
17:36 < bradleymeck> mornin
18:22 < trevnorris> indutny/tjfontaine: Just fyi, now w/ AL code complete going to just hammer through all my assigned tickets.
18:22 <@indutny> morning
18:22 <@indutny> great
18:23 <@indutny> tjfontaine: v0.12 time ? :)
18:23 <@indutny> I mean branch, obviously
18:25 <@indutny> ryah: hey man
18:25 <@indutny> long time
18:25 <@indutny> how are you?
18:36 < trevnorris> indutny: cool if I upgrade v8 to 3.24.35.20?
18:44 <@indutny> trevnorris: sure, but reapply patches
18:44 <@indutny> we have one
18:45 < trevnorris> will do
18:47 < trevnorris> indutny: seems they fixed 3421d29
18:47 <@indutny> oh, great
18:47 <@indutny> no point in floating it then
18:47 <@indutny> :)
18:49 <@indutny> I have a great tech idea
18:49 < trevnorris> heh, what's that?
18:49 <@indutny> trevnorris: have a minute?
18:49 < trevnorris> sure
18:49 <@indutny> trevnorris: ok, so this is an app
18:49 <@indutny> you photograph and upload the panel of some device
18:49 <@indutny> and it gives you an instruction on how to use it
18:49 <@indutny> would help me a lot today :D
18:49 <@indutny> haha
18:50 <@indutny> should be relatively simple to implement
18:50 < trevnorris> heh, if you could do that you'd definitely make money.
18:51 < trevnorris> take a picture of a device and it will auto detect the correct user's manual
18:51 <@indutny> yes, indeed
18:51 <@indutny> better a user-uploaded video
18:51 <@indutny> by other person
18:51 <@MI6> joyent/node: Trevor Norris master * 8d6fa72 : v8: upgrade to 3.24.35.22 - http://git.io/djfrZQ
18:51 <@indutny> who had struggled with this device
18:51 <@indutny> and figured it out
18:51 <@indutny> or just a manufacturer
18:52 < trevnorris> haha. that would be awesome.
18:52 <@indutny> ok, thanks for listening
18:53 <@indutny> sadly, I am bad at pitching and running the business :)
18:53 <@indutny> so perhaps, I'll just continue hacking on apps
18:53 <@indutny> :D
18:55 <@MI6> joyent/node: Trevor Norris hgraph-backport * ffed58d : v8: backport HGraphBuilder patch - http://git.io/QZJ8Lw
18:55 <@indutny> what's that? ^
18:55 <@indutny> mraleph's stuff?
18:55 <@indutny> yeah
18:55 <@indutny> ok
18:55 < trevnorris> yeah. I'm just keeping it on another branch
18:55 < trevnorris> for those who want to use it
18:56 < trevnorris> hm. wonder why they stopped maintaining the changelog for bleeding_edge
18:56 <@indutny> have no idea
18:57 <@indutny> https://github.com/joyent/node/pull/7394#issuecomment-39243987
18:57 <@indutny> hahaha
18:57 < trevnorris> indutny: wtf. they have 3.26 out. which means 3.25 is now stable!
18:57 < trevnorris> can we please upgrade?!?!!?
18:57 <@indutny> yes
18:57 <@indutny> I remember now
18:57 <@indutny> that ben told me about it
18:58 <@indutny> trevnorris: I'll need to verify ben's patch first
18:58 < trevnorris> ok
18:58 <@indutny> this is rather boring
18:58 <@indutny> but the rule of thumb is to trust only users with commit bits
18:58 < trevnorris> heh. well I already did the upgrade locally and it went smooth.
18:59 <@indutny> that's not what I meant :)
18:59 < trevnorris> yeah yeah. I know. :)
18:59 <@indutny> I had to check that this is indeed a v8 version from upstream
18:59 <@indutny> not from hackstream
19:00 <@indutny> lol :D
19:01 < trevnorris> indutny: though I'm a bit confused. The latest in v8 is 3.25.28.2, but his patch says 3.25.30
19:01 <@indutny> http://v8.googlecode.com/svn/tags/3.25.30/
19:01 <@indutny> AFAIK
19:02 <@indutny> hm...
19:02 <@indutny> but not on github
19:02 <@indutny> whatever
19:03 < trevnorris> indutny: wtf. there is a 3.25.30 tag from github. but it's not on the 3.25 branch
19:03 < trevnorris> think they might have had some tooling issues again like before?
19:04 <@indutny> yeah
19:04 <@indutny> perhaps
19:04 <@indutny> asked ben about it
19:33 <@MI6> joyent/node: Andrew Low master * f984555 : test: make test-smalloc endian aware - http://git.io/XC_Ijg
19:55 < trevnorris> tjfontaine: you alive?
20:30 < trevnorris> indutny: in irhydra in the lithium output there's a lot of entries like [rcx|R]. do you know what the |R is for?
20:31 <@indutny> register
20:32 <@indutny> that means that the register was required here
20:32 <@indutny> so it couldn't be a stack slot
20:32 <@MI6> joyent/node: Ben Noordhuis master * c7214fe : src: fix up after v8 upgrade (+2 more commits) - https://github.com/joyent/node/compare/f984555d4729...c7214fe35559
20:34 < trevnorris> indutny: i'm not convinced that 3.25.30 is actually a 3.25 release. do a $ git diff origin/3.25 3.25.30
20:35 <@indutny> trevnorris: we'll figure it out tomorrow :)
20:35 <@indutny> trevnorris: could you please open an issue?
20:35 < trevnorris> srlsy?
20:35 < trevnorris> you mean w/ node or w/ v8?
20:42 < trevnorris> oh hell, there's now a v8 native promise api
20:52 < bradleymeck> trevnorris: well promises are going to be part of es6 so it makes sense
20:53 < trevnorris> bradleymeck: it's more of the, "well, now that they're there might as well use them" issues that will inevitably come.
20:54 < bradleymeck> mmm unsure using promises in core would be beneficial if we would have to wrap/unwrap them
20:54 < bradleymeck> changing core APIs would be… ugly
20:58 < trevnorris> yeah, exactly. but there are enough people that think core should use promises for some things that they'll make noise.
21:00 < mmalecki> bradleymeck++
21:08 < bradleymeck> I mean for some chaining the native promises could be useful, but I am unsure how value propagation works with the C++ api
21:33 < groundwater> hey lars2893, bradleymeck is the guy working on node bundling
21:34 < bradleymeck> yo
21:36 < lars2893> Hey there, nice to meet everyone, I'm from New Relic in Seattle. I'm working on a command line utility (comparable to npm) and I happen to be using Node, but my management chain would like to abstract that away from the enduser, so this bundling tool sounds perfect.
21:37 < bradleymeck> lars2893: do you use native modules in it?
21:38 < bradleymeck> if so some temprorary files would still be created/deleted when they are loaded due to how OS work, similar to JAR file conventions
21:38 < lars2893> Nope, very conscious about not including native modules, I also care very strongly about cross-plat support (currently the code I have works seamlessly across all our platforms
21:38 < bradleymeck> well the idea is pretty simple for the bundler these days
21:39 < lars2893> Essentially the tool just downloads tar.gzs, extracts them, copies some config files, and then sets up /etc/init.d scripts or windows services and kicks them off
21:39 < groundwater> Simple is good!
21:39 < lars2893> Pretty bare bones Node use case, so we should be perfectly suited to help each other :)
21:39 < bradleymeck> we put a trailing zip archive onto a node executable built to be able to load zip archives, it then will attempt to load process.execPath
21:40 < mmalecki> why a zip?
21:40 < bradleymeck> lars2893: http://bmeck.github.io/ might be useful as a starting point v0.10-bundle branch of github.com/bmeck/node is also ugly but useful if you want to build by hand
21:40 < lars2893> Ah, so I would distribute the new node executable and then a separate zip archive with my specific files? 
21:41 < bradleymeck> mmalecki: zip archives have directory at end of file, so we can search for it quickly rather than trying to include the size of the node executable during executable compilation
21:41 < bradleymeck> lars2893: no you just concat the 2 together into 1 file
21:41 < mmalecki> ah, fair enough
21:41 < lars2893> I see, so from an end user perspective they just run an exe?
21:41 < bradleymeck> yes
21:42 < lars2893> That, sir, is what I need.  I am a little bogged down for the time being but will keep you posted when I get a chance to spike things.
21:42 < bradleymeck> sounds good
22:08 -!- mode/#libuv [+o sblom] by ChanServ
22:16 < saghul> "fatal: protocol error: expected sha/ref, got 'GitHub SSH access is temporarily unavailable'"
22:16 < saghul> sigh
22:17 < jirwin> saghul: yeah :/
22:17 < jirwin> https://status.github.com/
22:17 < saghul> yep, lets see if it's over quick
22:32 < trevnorris> CURSE YOU GITHUB
22:32 < LOUDBOT_> LIMEPI DO WE HAVE AN ARRANGEMENT
23:24 <@MI6> joyent/libuv: Saúl Ibarra Corretgé master * 3558d65 : unix, windows: do not set SO_REUSEADDR by default on udp - http://git.io/C-JLlQ
23:27 <@MI6> joyent/libuv: Saúl Ibarra Corretgé master * 7a4c42a : unix: add UV_HANDLE_IPV6 flag to tcp and udp handles - http://git.io/cO644Q
--- Log closed Wed Apr 02 00:00:40 2014