On Sun, 30 Jun 2013 20:24:51 +0200, Sönke Ludwig wrote:

Yes, this is still unprotected from the early times with no threading
support - needs to be changed. If everything is to be handled correctly,
the HttpServerSettings.sessionStore would also have to be a
shared(SessionStore). I'm a bit reluctant to go forward with that on a
broad scale, though, as D still needs some work in that area and some
tendencies in recent discussions made me a bit nervous that a final
solution might be incompatible with the shared system that I envision
and try to emulate with the stuff in vibe.core.concurrency.

And, as far as I remember, event loops are thread-local too, sharing single socket using OS help?

I don't think that simply marking something with "shared" will do anything positive. On its own it is a no-op at best and potential cause for issues with qualified type mismatch. It can me made shared AND server code update with internal async locking mechanisms to make stuff magically work out-of-the box but it does not seem like a good approach. It is extremely hard to do such stuff in generic form without severely harming concurrent performance - and that is the main reason to use worker threads after all.

Perfect approach in my opinion would have been to treat worker threads as independent processing nodes, with easier tools for inter-node data sharing in user code, but completely thread-local on server part. However, to be actually usable that requires configurable load sharing algorithms for incoming requests so that requests from same source will always get to same thread. Does that sound implementable?