Core Block

[mikeal]

Being that talks are only 20 minutes it would be a good idea to get an understanding of what each speaker is talking about so that we can order the talks in such a way that we can limit overlap and let the talks build on each other a bit.

@piscisaureus @trevnorris @rjrodger what are you thinking?

[trevnorris]

Just to clarify, you want us talking along the lines of the how and why of core code decisions?

@piscisaureus if you already have a topic in mind I'll just work from that.

[mikeal]

Interesting features/stories from core is all we care about. The point of flushing out some of the content in the thread beforehand is so that we can order them in such a way that you can actually succeed in 20 minutes. With more complex or hardcore topics it'll be hard to get the background in to your 20 minute slot so it is a good practice to have someone touch on it ahead of time in their talk.

For instance, if changes coming down from libuv are impacting stuff @trevnorris is working on we should try to work that in to @piscisaureus' talk and put him before you.

Of course, I'm not aware of all the interesting things happening in core right now that you might want to talk about so I'm just guessing/imagining until you guys fill in a few ideas.

[mikeal]

they just did an episode of NodeUp that covered that pretty well :)

[trevnorris]

@hij1nx fyi, it's episode 50. don't see it up yet.

[mikeal]

i listened live today, it was quite good.

[piscisaureus]

In my talk I will be making the case for extending the "conceptual model" of async things in node. The goal is to make proper error handling super easy, avoid double/missed callbacks etc.

I know this sounds incredibly vague. The good news: it probably won't overlap with any other talk except if someone was going to talk about domains.

[trevnorris]

@piscisaureus great. and my religious hatred of domains will prevent me from ever speaking about them. :)

@rjrodger Have an idea about your topic?

[trevnorris]

@piscisaureus ironically I'm working on an api that will allow users to add their own domain-like functionality. Purpose is two fold:

1. To shut everyone up that's looking for, what is imo, ridiculous amounts of error handling.
2. Prevent any of that from hurting core performance.

First is a patch that allows users to cheaply detect in js or c++ whether they're in a domain (nodejs/node-v0.x-archive#6019). After that gets in then I'll be able to finish the patch that exposes the generic api (nodejs/node-v0.x-archive#6011). Afterwards we'll be able to implement domains directly on top of the new api.

Hopefully all this is in before we speak, but thought it'd be information relevant to your topic.

@mikeal for lack of a better idea, you think everyone'd like to learn about techniques Node is using to get around things that usually require a sacrifice in functionality or performance? For example, sharing state between js and c++. Or maybe even a talk like "what insanity you can expect from core code (i.e. explanations of all the ridiculous tricks used to make all the things fast)"?

[mikeal]

@trevnorris i think that would be a great talk i'm just not sure which order you and @piscisaureus should go in. which talk is going to cover more background or fundamentals?

[trevnorris]

From how @piscisaureus made it sound mine probably would, but he'll have to verify that.

[rvagg]

@trevnorris fwiw (this is not my block so excuse my interjection), performance is always a great topic, everyone's always after performance info, whether it be what's going on in core or some of the stuff that you've learnt from hacking on core that we can apply in user-land. Given your bent towards performance, I reckon this would be a fantastic topic from you, I've love to hear it anyway!

[trevnorris]

@rvagg There will be a fair amount of information about core's native side. I'll try to keep it high level enough and provide examples everyone can study afterwards.

Then my talk will be on optimizations that core has used, with the goal to help developers know what to expect if they decide to jump in.

[piscisaureus]

@trevnorris Of course I can't stop you from talking about addAsyncListener. However I think you'll have a hard time doing an interesting talk about just that.

Just a suggestion - maybe you can talk about the buffer work you've been doing. I think many people have noticed the memory "leaks" (I think "multiplier" would be a more accurate description) that happened because of the different slab allocators. However not many people actually understand why we were doing that, and how you improved on it.

[trevnorris]

Oh, I'm planning on talking about all the performance tuning techniques
we're using in core. The things that seem to confuse users when they dive
into core for the first time (e.g. state sharing between JS and C++). No
plan on talking

[trevnorris]

Let's finish that thought.

@piscisaureus I have no plans on speaking on anything even closely related to domains. An example of one thing I'll be speaking on are the techniques used to share state between C++/JS w/o any of the overhead of passing arguments back and forth.