Day 11 - request context : a necessary evil ?

I'm right in the modules and more precisely the module context. First, let me try to explain the idea.

Let's say you write a module that gets a domain as input and submits a request to various search engines (google, yahoo, bing) to figure out how many pages each of them indexes for this domain. You know nginx is asynchronous so you definitely should not be holding back while you are waiting for an answer from each of them. You should return to nginx saying "I have submitted my requests, come back to me when you have news from those connections". Now, nginx being a nice back will do exactly that : get back to you as soon as he has news from one of the search engines. Now, the problem is two-fold : first you have to figure which one and second you have to figure out when you are done. To do so, nginx offers you (the module developper) a mechanism called the module module context. It's fairly simple: it's a pointer to a memory zone you allocated and that nginx will keep for you as associated to this request and your module. Not only will it keep it for you, but it will also give it back to you if you ask nicely and provide a request. This is what I call an explicit context.

Now, when you are developing in a more "traditional way" (let's say PHP or Java) you don't bother about all this because the context is basically managed for you by the engine (it is both in the stack itself and/or in some thread-attached structure). The context is always associated with the thread and you don't have to bother. This is what I call an implicit context.

Both approaches are fine. The explicit context is geared towards performance at the cost of developers nightmares. The implicit context makes developers life easier but is suboptimal (you end up with a bunch of things you don't need in your context.

If I had a magic wand (or if I was smarter) I would create a programming model (or would that need to be a language of itself) where it would be easy to decide what to put in your context. You could decide to put "all sockets I'm going to open from now on" or the good-old stack, or some kind of closure (in the style of javascript where you end up with pretty much everything and the kitchen sink in your context). Food for thought...

As I'm already having trouble figuring out how a web server works, I'll forget about this and get back to my original journey.