--- Log opened Tue Apr 08 00:00:18 2014
00:08 <@tjfontaine> piscisaureus: i think it's easier to say where you shouldn't go :)
00:37 <@piscisaureus> trevnorris: threads have no callback
00:37 <@piscisaureus> trevnorris: the "callback" runs truly in parallel. Welcome to the good old world of threads.
00:38 <@piscisaureus> trevnorris: if you join(thread1); join(thread2) both thread1 and thread2 run in parallel
00:38 <@piscisaureus> the main thread first awaits thread1 to complete and then thread2 to complete
00:39 <@piscisaureus> trevnorris: so the problem with that test is that 1e6 threads cannot exist at the same time
00:39 <@piscisaureus> you could create 1000 and then await the 1st before creating the 1001th
00:39 <@piscisaureus> so you are sure there are never more than 1000 at the same time
00:42 < trevnorris> ok. so i'm a little confused by "in parallel". to me, that makes it sound like each thread is executed at the same time.
00:44 < trevnorris> wait. got it. thanks for the explanation
00:48 <@piscisaureus> trevnorris: haha
00:48 <@piscisaureus> trevnorris: yes each thread is executed at the same time more or less
00:51 -!- mode/#libuv [+o TooTallNate] by ChanServ
00:54 < trevnorris> piscisaureus: yeah. just got it. the thread is executed on create, but then join pauses the main thread until the passed thread has completed. correct?
00:57 <@piscisaureus> trevnorris: right on!
00:57 <@piscisaureus> trevnorris: and join also cleans up the resources that were allocated for the thread
00:58 < trevnorris> you mean if I don't join the thread then the thread's stack won't be cleaned up?
00:59 <@piscisaureus> trevnorris: not sure about the stack. The posix spec doesn't say.
00:59 <@piscisaureus> trevnorris: "Failure to join with a thread that is joinable (i.e., one that is not detached), produces a "zombie thread". Avoid doing this, since each zombie thread consumes some system resources, and when enough zombie threads have accumulated, it will no longer be possible to create new threads (or processes)."
01:00 <@piscisaureus> trevnorris: the alternative is to "detach" a thread - after that you can no longer join a thread (nor do you need to)
01:00 <@piscisaureus> the same can be implemented on windows, I'm not sure if we have a uv_thread_detach api at this point but we could add one trivially
01:01 < trevnorris> nope, uv doesn't
01:01 <@piscisaureus> trevnorris: most likely the error you're seeing is just the PID/TID table getting full
01:01 <@piscisaureus> or some ulimit
01:01 <@piscisaureus> ... being enforced
01:01 < trevnorris> yeah. that's the issue
01:01 < trevnorris> hitting the maximum number of allowed threads per process
01:05 -!- mode/#libuv [+o sblom] by ChanServ
01:30 <@piscisaureus> tjfontaine: thanks, good news :)
01:33 <@piscisaureus> tjfontaine: mere luck though :)
02:04 < Dirkson> Ok. So when my udp receive event fires, libuv hands me a sockaddr struct that contains the information about the sender. I cast this into a sockaddr_in struct in order to use it for my uv_udp_send. When I check the sockaddr_in struct's port, it is NOT the same as the destination port OR the source port. In short: How do I use an incoming packet's source port as its destination port?
02:05 < Dirkson> Er... How do I use an incoming packet's source port as its reply packet's destination port?
02:09 -!- mode/#libuv [+o TooTallNate] by ChanServ
02:18 < Dirkson> Heck, I'd be a little chuffed if I could suss out how to set the source port full stop.
02:57 <@piscisaureus> uv_udp_bind
03:03 < trevnorris> piscisaureus: ping
03:04 <@piscisaureus> trevnorris: sup?
03:05 < trevnorris> piscisaureus: pthread_self() is supposed to return a pthread_t. so I'd assume that uv_thread_self should return uv_thread_t, but instead it returns an unsigned long.
03:05 < trevnorris> piscisaureus: what am I missing?
03:05 <@piscisaureus> well there are two problems here
03:06 <@piscisaureus> the pthread_t could in theory be a struct but in practice it never is
03:06 <@piscisaureus> but that means that it's a bit questionable to return a long
03:06 <@piscisaureus> * to cast it to a long
03:06 <@piscisaureus> also
03:06 <@piscisaureus> pthread_self() is supposed to return a valid pthread_t but not necessarily the same one every time
03:06 <@piscisaureus> so
03:07 <@piscisaureus> depending on your use case it may or may not be suitable
03:07 <@piscisaureus> I think what people really want to be able to do is
03:07 <@piscisaureus> uv_thread_id t;
03:07 <@piscisaureus> uv_thread_id t1 = uv_thread_self();
03:07 <@piscisaureus> uv_thread_id t2 = uv_thread_self();
03:08 <@piscisaureus> assert(t1 === t2)
03:08 <@piscisaureus> which currently isn't guaranteed to work
03:09 < trevnorris> hm. interesting.
03:09 <@piscisaureus> so long story short ... it works but it's broken too
03:10 <@piscisaureus> so I don't know... I think that we should make uv_thread_self return an uv_thread_t or scrap it altogether
03:11 <@piscisaureus> and invent an uv_thread_id_t type and uv_thread_id() api for the purpose described above
03:11 <@piscisaureus> I wrote it in c++ for mozilla
03:11 < trevnorris> hm. yeah. it's only used in one place in node. node_crypto in crypto_threadid_cb()
03:11 < trevnorris> really? cool
03:12 < Dirkson> piscisaureus: More or less got that working. Still have yet to see bidirectional udp :-/
03:12 < trevnorris> piscisaureus: ok. so is the "thread id" basically the tid that uv_thread_self is returning?
03:12 <@piscisaureus> trevnorris: https://bug956899.bugzilla.mozilla.org/attachment.cgi?id=8362315
03:13 <@piscisaureus> trevnorris: yes, but casting pthread_self() to a long is not the right way to get it
03:13 <@piscisaureus> Dirkson: that doesn't exist. UDP is connection-less
03:14 < trevnorris> piscisaureus: yeah. i'm actually confused by the man page. the function is defined by: pthread_t pthread_self(void);
03:14 < trevnorris> but says "returns the ID of the calling thread"
03:14 < trevnorris> so how is pthread_t the id? I thought pthread_t was a struct
03:15 <@piscisaureus> It could be - the spec doesn't say.
03:15 <@piscisaureus> I think it's usually a void*
03:15 <@piscisaureus> trevnorris: http://man7.org/linux/man-pages/man3/pthread_self.3.html -- read the "notes" section
03:15 < trevnorris> ah, ok. it does say that it returns the same value as pthread_create(). which returns an int.
03:15 < trevnorris> ok
03:15 < Dirkson> piscisaureus: Bidirectional udp is commonly done, whether it officially exists or not? O.o I'm not sure how to reply to that.
03:16 <@piscisaureus> Dirkson: of course you can send UDP in two directions
03:17 < Dirkson>  piscisaureus *grins* No, no I cannot! But that's just my problem.
03:17 < trevnorris> piscisaureus: from those notes, and your comment above, it seems there should be a uv_thread_equal()
03:18 < Dirkson> I should probably explain what I've been trying to do for the past few hours, rather than just be grouchy about it.
03:18 <@piscisaureus> trevnorris: yes but that's just terrible :)
03:18 <@piscisaureus> trevnorris: also hard to implement on windows I'm afraid.
03:18 <@piscisaureus> trevnorris: well - the equal function is not hard to implement
03:19 < Dirkson> I've gotten a UDP packet to go from the client to the server, but not the reverse. As near as I understand, to do that I need to send the reply packet to the original's packet's source port. Actually getting that done, however, is proving Extremely challenging.
03:19 <@piscisaureus> trevnorris: but in order to actually return a usable thread_t that you can pass to uv_thread_join, you'd need to get the HANDLE
03:19 <@piscisaureus> but the thing with HANDLEs is that you need to close them
03:19 <@piscisaureus> so then we'd have to add uv_thread_close() :/
03:19 < trevnorris> hehe. it's a rabbit hole.
03:20 < trevnorris> does GetCurrentThreadId() have the same issue w/ == that you mentioned above?
03:20 <@piscisaureus> Yes. So the moz patch that I linked above solved that by having a separate "identity" type and a separate "handle" type
03:20 <@piscisaureus> where the handle type is what you can pass to pthread_join etc
03:21 < trevnorris> ah ok
03:21 < Dirkson> I'm honestly not sure what's going wrong right now. My router is noting the packets for port "56390" (My now hard-coded reply port) and manually forwarding them on (as a proof-of-concept), but wireshark doesn't see them... That's not a failure indicative of anything. Packets are getting dropped in the wire between my computer and my router??
03:21 <@piscisaureus> trevnorris: and the "identity" type is guaranteed to uniquely identify a thread (and nonzero) so you can compare with ==
03:21 <@piscisaureus> trevnorris: but if you have a better idea you're welcome :)
03:22 < trevnorris> hehe. dude, today is my first day trying to seriously use threads.
03:22 <@piscisaureus> Dirkson: that could happen but seems unlikely. What OS is this?
03:23 < Dirkson> piscisaureus: The client and server are debian linux, running libuv 10.25, and the router is a microtick routeros thingie.
03:23 < Dirkson> If I'm honest, I'm not sure I need a huge amount of help with anything right now, other than a place to vent and maybe a sandwich. I'm fried out on the problem, but too stubborn to stop trying for a while.
03:24 <@piscisaureus> Yeah I'm not aware of any issues with debian
03:24 < trevnorris> piscisaureus: i'm just experimenting, or at least trying to get to the point of being able to, of implementing a pull based API where the JS would run off the main uv_run() thread.
03:24 <@piscisaureus> trevnorris: on another thread?
03:25 < trevnorris> yeah. figured if I"m going to learn how to use this stuff might as well start with something insane. :P
03:25 < trevnorris> basically the incoming events would be pushed to different queue's then going around the uv_run event loop it would notify the JS thread that there are events waiting to be handled
03:27 < trevnorris> i was thinking that it might be useful if there was any pre-processing that should be done, before handing it off to the JS thread. like http header parsing, for example.
03:28 < trevnorris> no idea if this is even possible, but guess I'll find out. :)
03:28 <@piscisaureus> trevnorris: it certainly is possible
03:28 <@piscisaureus> trevnorris: I'd go about it a bit differently but it's not bad if you play a little bit with it :)
03:28 < trevnorris> coolio. thanks for all the help, and for the link to the patch
03:29 < Dirkson> Ok. Is sockaddr_in->sin_port the source port or the destination port?
03:30 <@piscisaureus> Dirkson: depends on which API you're using
03:30 < Dirkson> *confusion*
03:30 <@piscisaureus> Dirkson: sockaddr_in is an IP+port combo
03:30 <@piscisaureus> Dirkson: if you put the destination IP in there then you should also put the destination port
03:30 < Dirkson> Ah! Gotcha.
03:31 < Dirkson> piscisaureus: When uv_udp_send asks for a sockaddr_in then, is it asking for a destination port?
03:31 <@piscisaureus> Dirkson: yes
03:31 <@piscisaureus> Dirkson: if you put 0 in there it should send to a random port
03:31 < Dirkson> Awesome. I have a puzzler for you then.
03:32 < trevnorris> piscisaureus: part of the idea was that this way even if the JS was blocking you could still SIGINT the process and receive it.
03:32 < Dirkson> piscisaureus: http://pastebin.com/aziHfpur - This code outputs this: Outgoing Port: 71.59.172.169 : 18140    . I expect it to output the port 56390 instead - Why doesn't it?
03:32 <@piscisaureus> trevnorris: but who'd receive it
03:32 <@piscisaureus> trevnorris: if js is running you'd interrupt it?
03:33 < trevnorris> piscisaureus: yeah. v8 has an api for that. so then if you have a bocking script you'd still be able to jump into the middle of it and debug
03:33 <@piscisaureus> trevnorris: you could do the same by spinning up a separate event loop with only a sigint handler in it
03:33 <@piscisaureus> (in a separate thread)
03:34 <@piscisaureus> if that's all, there's an easy solution. Now there is something to say for cross-thread dispatch so I don't want to dis-encourage you to try this stuff.
03:34 < trevnorris> oh don't worry, you're not. :)
03:34 < trevnorris> when learning something new I like to jump in at the deep end.
03:35 <@piscisaureus> Dirkson: because of host vs machine byte ordering
03:35 <@piscisaureus> Dirkson: you have to ntohs() the port number
03:36 < Dirkson> piscisaureus: When where?
03:36 <@piscisaureus> sin_port is in network byte ordering, so it's not the port
03:36 <@piscisaureus> it's the port with the bytes reversed
03:36 <@piscisaureus> er, in reverse order
03:37 <@piscisaureus> Dirkson: you need to do this in reverse: https://github.com/joyent/libuv/blob/master/src/uv-common.c#L104
03:37 < Dirkson> piscisaureus: One mystery solved, another crops up. Thank you.
03:38 < Dirkson> piscisaureus: Oh. OH. Whenever I fuddle with the port number. No wonder nothing worked.
03:39 < trevnorris> piscisaureus: c question. are static variables inside functions thread safe?
03:39 < trevnorris> google is failing me
03:39 < Dirkson> piscisaureus: Does uv_udp_bind and other uv functions expect me to adjust byte order?
03:43 <@piscisaureus> Dirkson: well - you have to pass in a valid sockaddr_in which is supposed to have those values in network byte order
03:43 <@piscisaureus> Dirkson: if you create a sockaddr_in with uv_ipv4_addr that is done for you but if you populate the struct yourself you have to do it yourself
03:51 < Dirkson> piscisaureus: Thanks for the help.
03:55 <@piscisaureus> Dirkson: you're welcome, good luck
04:44 <@MI6> joyent/node: Fedor Indutny v0.10 * d6fd118 : deps: update openssl to 1.0.1g - http://git.io/oi6C4w
04:47 <@indutny> ok, let's do a v0.11
04:54 < guybrush> hey indutny bud is really cool! i wonder if it would be easy to support http-proxying too? or just use node for http-balancing?
04:54 <@indutny> guybrush: hey man
04:54 <@indutny> I was thinking about it
04:54 <@indutny> but then I thought that SNI should be enough
04:54 <@indutny> what's your use case?
04:54 < guybrush> the sni-feature is really nice and in general i fell in love with bud lol
04:55 <@indutny> great! :)
04:55 <@indutny> thank you
04:59 < guybrush> well im really a noob with all these things, but i dont see how i can use bud to point browsers to the https
04:59 <@indutny> hm... I think you need an http server running as a backend
04:59 < guybrush> right now i am setting the Strinct-Transport-Security header, but that only works after the first time
04:59 < guybrush> *Strict
05:00 < guybrush> so basically with bud i can du HTTPS->HTTP, but i cant do HTTP->HTTP right?
05:00 < guybrush> *do
05:01 <@indutny> yep
05:01 <@indutny> there are other, more powerful tools for it
05:01 <@indutny> :)
05:01 < guybrush> kk ty for the chat :D
05:02 <@indutny> np, you are welcome
05:02 <@indutny> btw
05:02 <@indutny> there is #bud-tls channel
05:02 < guybrush> oh sweet, will idle and shoot there if i run into some issues
05:03 <@indutny> great!
05:04 <@MI6> joyent/node: Alexis Campailla master * c20b209 : openssl: fix keypress requirement in apps on win32 (+8 more commits) - http://git.io/1tBzVA
05:23 -!- mode/#libuv [+o TooTallNate] by ChanServ
06:11 < trevnorris> indutny: wtf is up with deps/openssl/openssl/Makefile.bak ?
06:11 <@indutny> that's from upstream
06:11 < trevnorris> figured, but still. that and a Makefile.save
06:11 < trevnorris> wtf are they thinking?
06:11 < trevnorris> isn't that the point of revision control?
06:11 <@indutny> haha
06:11 <@indutny> perhaps
06:12 <@indutny> :)
06:12 < trevnorris> and like every subdir in deps/openssl also has a Makefile.bak and Makefile.save
06:13 < trevnorris> ok. so only 1 .bak
06:13 < trevnorris> but there are 57 Makefile.save
06:13 < trevnorris> oy
06:21 <@indutny> :)
06:21 <@indutny> trevnorris: working on a test for heartbeat CVE
06:21 <@indutny> it is quite interesting to see, how much data I could actually extract
06:24 < trevnorris> interesting
06:24 < trevnorris> i'm trying to wrap my head around handling multiple threads and signaling between them.
06:28 <@indutny> heh
06:28 <@indutny> rather interesting too
06:28 <@indutny> I suppose
06:30 < trevnorris> hey, for this being my first day ever trying to seriously work with threads it's a little mind bending
06:31 <@indutny> not joking, actually
06:31 <@indutny> and that wasn't sarcasm
06:31 <@indutny> sorry, if that sound otherwise
06:31 <@indutny> :)
06:33 < trevnorris> heh, no worries.
06:33 < trevnorris> when did the use of uv__ for internal functions start?
06:33 < trevnorris> src/win/internal.h is all over the place
06:36 <@indutny> I think it is quite old C tradition
06:37 < trevnorris> ok. just curious. maybe at one time some of those weren't internal. was just looking at uv_translate_sys_error
06:37 < trevnorris> since I was examining how uv_thread_join works
06:41 < trevnorris> indutny: so, I think I get how to use uv_async and uv_work to create handles and send work to the uv thread pool.
06:41 < trevnorris> i might be off my rocker, but is there a generic way to create a thread and have it chill in the background and wait for a signal from the main thread?
06:42 <@indutny> you need a semaphore
06:43 <@indutny> but if you meant just one API method
06:43 <@indutny> then answer is no
06:43 < trevnorris> cool thanks
06:48 < trevnorris> indutny: mind running ./run-benchmarks tcp_multi_accept2
06:48 < trevnorris> and tell me if it works for you?
06:49 <@indutny> perhaps a bit later
06:49 <@indutny> in the middle of different thing right now
06:49 <@indutny> sorry
06:49 < trevnorris> no worries
06:50 < trevnorris> i'm just getting:
06:50 < trevnorris> Assertion failed in ../test/benchmark-multi-accept.c on line 354: 0 == uv_tcp_connect(&ctx->connect_req, (uv_tcp_t*) &ctx->client_handle, (const struct sockaddr*) &listen_addr, cl_connect_cb)
06:50 < trevnorris> and not sure if it's something i'm doing wrong
06:51 <@indutny> it might be broken
06:53 <@indutny> oh god
06:53 <@indutny> it works
06:53 <@indutny> the heartbeat leak
06:53 < trevnorris> hehe
06:58 < trevnorris> indutny: oh, hah. it's failing because of EADDRNOTAVAIL
06:58 <@indutny> ah
06:59 <@indutny> I see
07:09 <@indutny> so the question
07:09 <@indutny> is how to identify private keys in memory
09:46 -!- mode/#libuv [+o MI6] by ChanServ
10:29 -!- mode/#libuv [+o ryah] by ChanServ
14:11 < swaj> So node.js v0.10.x bundles a version of OpenSSL that is affected by heartbleed
14:13 < swaj> and actually so does node 0.11.x
14:16 < saghul> swaj: heartbeat was disabled since 0.10.2
14:17 < swaj> I just saw in the gyp file :P
14:49 <@tjfontaine> swaj: you should follow @nodejs ;) I tweeted it yesterday
14:50 <@tjfontaine> indutny: ping
14:54 <@tjfontaine> morning chrisdickinson
14:57 < Domenic___> There is no backpressure mechanism for UDP, right?
14:58 <@tjfontaine> that depends on what you mean
14:58 <@tjfontaine> you don't have to call recv() in your code until you're ready -- which leaves it in the kernel -- so effectively your code is leaving the buffer work to the kernel
14:59 <@tjfontaine> but that is not communicated back to the sender
15:02 < Domenic___> ah ok
15:04 < Domenic___> are there benefits to leaving it in the kernel buffer vs. user-space buffer?
15:04 <@tjfontaine> fewer copy outs until it's absolutely necessary
15:06 < ktosiu> /quit
15:07 < Domenic___> that makes sense. thanks.
15:56 <@tjfontaine> isaacs: wtf generates changelog.html :P
15:57 <@tjfontaine> ah I see
16:10 <@MI6> joyent/node: Timothy J Fontaine v0.10 * af69f88 : build: make sure changelog.html is generated - http://git.io/JKJyzA
16:26 < chrisdickinson> morning tjfontaine
17:06 -!- mode/#libuv [+o TooTallNate] by ChanServ
17:36 -!- mode/#libuv [+o TooTallNate] by ChanServ
17:57 -!- mode/#libuv [+o sblom] by ChanServ
18:04 -!- mode/#libuv [+o sblom] by ChanServ
18:08 -!- mode/#libuv [+o sblom] by ChanServ
18:48 < Dirkson> Is there any way to tell if I'm on a host with ipv6 support, other than "try to send ipv6 packet, record if it fails"?
18:48 < bradleymeck_> you could use the OS calls or check config. but it is not built in
18:54 < bradleymeck__> https://gist.github.com/bmeck/0deeefd070224c10566f , need to flesh it out more but a decent start to speccing out the archive loader
19:01 < Dirkson> bradleymeck: Well, OS support only determines whether the machine supports ipv6, right? Not whether we have access to the ipv6 net.
19:01 < bradleymeck> Dirkson: correct, but you can’t query that generally
19:01 <@tjfontaine> finding out if a path is routable is different from finding out if your environment has ipv6 enabled -- but that's also true of ipv4
19:02 <@tjfontaine> brb
19:02 < Dirkson> bradleymeck: tjfontaine: Gotcha. So it's probably best to attempt an ipv6 packet on the first run of my program, then store the successful/unsuccessful result to determine which ipversion to use in the future?
19:04  * bradleymeck ponders if OS DNS only returns ips in supported versions
19:04 < bradleymeck> well s/DNS/networking interfaces/
19:04 < Dirkson> Hmm. There's a question, too. If the /machine/ doesn't have ipv6 support, when will my networking setup/use fail? When I try to bind the ipv6 address? Or when I try to send an ipv6 packet?
20:06 < groundwater> bradleymeck: can i bundle compiled code for multiple platforms into a single bundle?
20:06 < bradleymeck> groundwater: mmm no that would require some work to support fat bundles
20:07 < groundwater> bradleymeck: okay, i just wanted to clarify
20:07 < bradleymeck> it would be possible but even then you would still need to keep separate node binaries for each platform to bootstrap the bundles
20:08 < groundwater> bradleymeck: no readResource async method?
20:08 < groundwater> bradleymeck: i should lead with "i really like this"
20:08 < bradleymeck> groundwater: no point to it since in-memory files are intended to be loaded sync for the require
20:09 < bradleymeck> if you are loading application assets async I would recommend using createReadStream
20:10 < bradleymeck> we could fake out async readResource, but I am unsure why you would want that over streams generally
20:10 < groundwater> does readResourceSync always pull from memory?
20:10 < bradleymeck> was trying for minimal API coverage and expand as people’s needs arise
20:10 < groundwater> oh i'm just thinking of what random people on the internet will expect to see / recognized
20:10 < bradleymeck> no, readResourceSync pulls from w/e loader context you are in
20:11 < bradleymeck> in archives it is from memory (for now but thats a long story on how to try and lower bundle footprint), from file loader it is off disk via IO
20:13 < groundwater> i think streams are still confusing for many people, it may be worth having a readResource async call because not everyone is going to bundle their apps, but you do want them to be bundle compatible
20:14 < bradleymeck> fair enough, ill update the code and spec tonight
20:14 < bradleymeck> not doing offsets though, complexity due to encoding/compression in archive ruins it
20:15 < groundwater> so you mean all or nothing?
20:15 < bradleymeck> yea
20:16 < bradleymeck> I can’t jump into something that was deflated at offset X without inflating everything before it. would cause soo many oddities about performance
20:19 <@tjfontaine> I need to pull up the spec, but I think any resource load should return a stream -- the fact that the stream is sync is an implementation detail of being in bundled mode
20:19 < bradleymeck> kind of the same reason I do not want bundles to be in multiple files even though the .zip format supports them via headers
20:19 < bradleymeck> tjfontaine: right now streams force a nexttick
20:20 <@tjfontaine> right
20:21 < bradleymeck> do we have any other examples of sync streams? would want at least a way to test if a stream is sync
20:21 <@tjfontaine> not a good one, but lemme pull the spec here -- just a second
20:27 <@tjfontaine> bradleymeck: in this spec, lets ignore trying to work (for the moment) with existing versions of node
20:28 <@tjfontaine> bradleymeck: what if we used the magic bytes in the header of the file
20:28 < bradleymeck> oh, it breaks some things
20:28 < bradleymeck> we cant get 100% on older node
20:28 < bradleymeck> but we can get like 98%, so I think focusing on future is best
20:28 < bradleymeck> tjfontaine: in the zip header? for what
20:28 <@tjfontaine> so instead of .noda we could just use .node
20:29 < groundwater> tjfontaine: part of the value of this is that other module authors buy into a bundle-compatible format, even when they're not bundling themselves, i think you'll want a readResource async method just because it's *easy*
20:29 <@tjfontaine> if it's elf or macho we know it's a binary, if it's zip or gzip
20:29 <@tjfontaine> bah I have a call in 3 mins
20:30 < bradleymeck> tjfontaine: we can do that, but I might test against zip instead of if it is a binary, zip header only needs 64k of trailing bytes to do full check
20:30 < bradleymeck> it works same across platforms as well
20:31 <@tjfontaine> I'm just thinking there may be multiple mime types we want to support
20:32 < bradleymeck> as long as the mime types contain a central directory, sounds fine
22:03 < trevnorris> tjfontaine: think you might be able to answer a uv question?
22:03 <@indutny> tjfontaine: pong
22:03 <@tjfontaine> can try
22:04 < trevnorris> ooh, indutny is here too. ok for either of you: https://gist.github.com/trevnorris/10191522
22:04 <@tjfontaine> indutny: do we have our own test case for heartbleed we can include?
22:04 <@indutny> tjfontaine: nope, and I don't really enjoy making it
22:04 <@indutny> though I have a patched node
22:04 < trevnorris> for some reason the uv_async_send() in worker_cb() isn't triggering the parent_cb()
22:04 <@indutny> that could send broken heartbeats
22:04 < trevnorris> just sits in epoll_wait
22:05 <@indutny> trevnorris: uv_stop() isn't thread safe
22:05 <@indutny> I think
22:05 < trevnorris> ok, i can fix that.
22:06 < trevnorris> but i'll worry about that once the code can actually reach that point. :)
22:06 <@indutny> which point?
22:06 < trevnorris> needing to call uv_stop(). right now it calls parent_cb() then worker_cb(), but never reaches parent_cb() again
22:07 < trevnorris> i'm just trying to bounce between two threads using uv_async_send() but for some reason at one point it's getting hung up
22:08 <@indutny> ah
22:09 <@indutny> erm
22:09 <@indutny> why are you setting
22:09 <@indutny> data = &comm
22:09 <@indutny> instead of just comm
22:09 <@indutny> isn't comm a pointer?
22:10 < trevnorris> haha
22:10 < trevnorris> damn it
22:10 < trevnorris> copy pasta from main()
22:11 < trevnorris> there. freak. can't believe that was it.
22:11 < trevnorris> thanks indutny.
22:11 <@indutny> :)
22:11 <@indutny> np
22:11 <@indutny> you are welcome
22:13 <@tjfontaine> copy paste is a bad thing
22:14 <@indutny> tjfontaine: https://github.com/joyent/node/issues/7415
22:15 <@indutny> tomorrow is a freeze
22:15 <@indutny> we need to figure out something on this
22:25 <@indutny> oh, not again :)
22:25 <@tjfontaine> hm?
22:25 <@indutny> tjfontaine: do not disappear!
22:25 <@indutny> :)
22:25 <@tjfontaine> Im here, getting trolled by someone saying they have yahoo's secret key because of heartbleed
22:25 <@indutny> hahahah
22:25 <@indutny> that's very likely
22:26 <@indutny> though, it is a bit complicated to extract it from memory dumps
22:26 <@tjfontaine> it's likely that yahoo could have been hit --- but not by this guy
22:26 <@indutny> I haven't got that far to it
22:27 <@indutny> I guess to do this - you need to search for some kind of signatures
22:27 <@tjfontaine> he claims he just used gdb locally to figure out a hueristic
22:27 <@tjfontaine> anyway, I know this guy is full of shit
22:27 <@indutny> hahaha
22:27 <@indutny> ok
22:27 <@tjfontaine> if this code exists, he did not write it
22:27 <@indutny> what about SO_REUSEADDR
22:28 <@tjfontaine> having it off by default is right, it's required for multicast?
22:28 <@indutny> yes, this is correct
22:28 <@indutny> what I am really interested in
22:28 <@indutny> is a method to enabling it
22:29 <@indutny> do we need to introduce a new method
22:29 <@indutny> or
22:29 <@indutny> a flag argument to .bind()
22:29 <@indutny> https://gist.github.com/indutny/df1800682a70d07eea75
22:29 <@tjfontaine> I'm not sure a .bind argument makes much sense unfortunately
22:29 <@indutny> btw ^
22:29 <@indutny> tjfontaine: so a method
22:30 <@tjfontaine> ya, which is implicitly called for multicast work
22:33 <@tjfontaine> indutny: I'm not sure how much like setKeepAlive it should be
22:33 <@tjfontaine> indutny: is it only valid on socket creation or can it be set anytime?
22:35 <@indutny> hm...
22:35 <@indutny> could socket be re-bound?
22:36 <@tjfontaine> it's a flag that can only be set during binding, and there's an implicit bind if the socket has yet to be bound -- sorry I'm remembering this api now
22:36 <@indutny> yep
22:36 <@indutny> so we need a method
22:36 <@indutny> or
22:36 <@indutny> an option
22:36 <@indutny> :)
22:36 <@indutny> let's stick to option
22:36 <@indutny> I'm not particularly fond of a new method
22:36 <@tjfontaine> yes, option
22:37 <@tjfontaine> can you bind, and then set multicast?
22:37 <@indutny> hm...
22:37 <@indutny> I suppose no
22:37 <@indutny> saghul: ^
22:46 <@indutny> tjfontaine: right now it is createSocket(type, listener)
22:46 <@indutny> we could make alternative signature for it
22:46 <@indutny> createSocket(options, listeners)
22:46 <@indutny> where options could contain
22:46 <@indutny> type
22:46 <@indutny> and
22:46 <@indutny> reauseAddr:
22:46 <@indutny> properties
22:46 <@tjfontaine> yes, and then we can support unix dgrams some day
22:46 <@indutny> yep
22:46 <@tjfontaine> sold
22:46 <@indutny> so, sounds good
22:46 <@indutny> ok
22:53 < trevnorris> wow, bouncing between threads is not a cheap thing.
22:53 <@indutny> :)
22:53 <@tjfontaine> context switching, as it turns out, is expensive -- and the more locking you dothe worse it becomes
22:53 <@indutny> async_send isn't cheap
22:53 <@indutny> meh
22:53 <@indutny> it is all async_send
22:53 <@indutny> and synchronization, of course
22:53 <@tjfontaine> sure, which has to lock
22:54 <@indutny> yeah, in kernel
22:54 < trevnorris> any magical way to get around that?
22:54 < trevnorris> i mean, it's more expensive then context switching from js to c++, and I find that sort of sad.
22:54 <@tjfontaine> yes -- event driven programming
22:54 <@tjfontaine> :)
22:56 <@indutny> trevnorris: use less synchronization
22:56 <@indutny> this is the only way to work around it
22:56 <@indutny> lock-less structs
22:56 <@indutny> producer-consumer objects
22:56 <@indutny> erm
22:56 <@indutny> queues
22:56 <@tjfontaine> http://en.wikipedia.org/wiki/Non-blocking_algorithm
22:57 < trevnorris> yeah. still figuring out all these different things w/ threads.
22:57 <@tjfontaine> what are you actually trying to do -- what are you looking to solve for?
22:57 < trevnorris> I want the cheapest way possible to ping a thread, and have that thread run a callback.
22:58 < trevnorris> screw synchronization and all that.
22:58 <@indutny> without pinging back?
22:58 <@indutny> I think you'll still need some sort of synchronization
22:58 <@indutny> to let other thread know about new changes
22:59 <@indutny> otherwise you'll need to poll
22:59 < trevnorris> well, yeah, it'll have to ping back.
22:59 <@indutny> ok
23:00 < trevnorris> i'm coming from this from the js side. I think of it like this. call callback A (which is a function in another thread) then when it's done it'll call callback B (in the originating thread). but the difference is say that each js function is self contained (meaning they don't affect the global scope) so they could technically run simultaneously.
23:01 <@tjfontaine> you're trying to do isolates in node again
23:01 <@tjfontaine> is what you're saying
23:01 < trevnorris> no no.
23:01 < trevnorris> i'm just saying that's the paradigm i'm used to
23:01 < trevnorris> and i'm trying to translate that to what it means in C, using threads
23:02 <@indutny> you need dispatch_queue
23:02 <@indutny> :)
23:03 <@tjfontaine> blocks?
23:03 <@tjfontaine> :)
23:03 <@tjfontaine> http://en.wikipedia.org/wiki/Grand_Central_Dispatch
23:03 <@indutny> AFAIK, it is one of the most robust systems 
23:03 <@tjfontaine> ya
23:03 <@tjfontaine> with blocks or c11 you get closures as well
23:04 <@tjfontaine> it's like you have javascript in C :P
23:04 < trevnorris> ....
23:04 < trevnorris> i just threw up a little in my mouth
23:04 < trevnorris> are all languages slowly converging?
23:04 <@tjfontaine> it's not as scary as it sounds
23:08 < trevnorris> ok. so it's a lot cheaper to create a thread and have it poll, waiting for something to come in?
23:09 <@indutny> tjfontaine: https://github.com/joyent/node/pull/7430
23:10 <@indutny> tjfontaine: erm
23:10 <@indutny> trevnorris: erm
23:10 <@indutny> trevnorris: not exactly
23:10 <@indutny> but in some cases busy-looping is faster than using synchronization primitives
23:10 <@indutny> though it is quite rare
23:10 <@indutny> ok
23:10 <@indutny> ttyl, guys!
23:10 < trevnorris> see ya
23:16 < Dirkson> What is uv_listen's second argument, "backlog" for?
23:19 < trevnorris> Dirkson: man 2 listen
23:19 < trevnorris> same backlog
23:19 < Dirkson> trevnorris: Thanks. Basically, how many queued connection requests will be accepted before they start dropping?
23:20 < trevnorris> yeah, how many queued connections before receiving ECONNREFUSED
23:20 < Dirkson> Cool : )
23:20 < Dirkson> Thanks!
23:20 < trevnorris> yup :)
23:23 < doy> so if i need to do more initialization between fork and exec than the uv_spawn api allows for, do i have any other options than just handling all of the fork/exec logic myself?
23:24 < trevnorris> nope. we do the same thing in node
23:24 < doy> bah
23:47 <@tjfontaine> doy: what all do you want to do?
23:48 < doy> trying to write a terminal emulator, need to do things like set the controlling tty, etc
23:57 <@tjfontaine> trevnorris: btw, you might interested to see how this works https://github.com/joyent/v8plus/blob/master/v8plus_csup.c#L172-L180 :P
23:58 < trevnorris> tjfontaine: oooh. cool.
23:59 <@tjfontaine> trevnorris: LeftWing wrote all that, he can provide you context around it if you have questions
23:59 < LeftWing> Sure can.
23:59 < trevnorris> awesome. thanks for the resources.
--- Log closed Wed Apr 09 00:00:24 2014