Am 01.07.2013 11:44, schrieb Dicebot:> 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?

Exactly.

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.

Together with the lock() function in vibe.core.concurrency and Insolated!T it becomes a pretty useful tool to get type-safe, race-free shared memory access. lock() will internally cast away shared in a controlled scope, but only if it is safe to do so (e.g. it can be statically proven that no reference to shared memory escapes the scope).

The recent improvements in the compiler regarding unique(/"isolated") expressions will help making this even more useful, although some current limitations actually have made DMD 2.063 more cumbersome to work with (http://d.puremagic.com/issues/show_bug.cgi?id=10012, this unfortunately broke some valid constructor calls and now requires using cast).

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?

Worker threads can be considered independent processing nodes (with the exception of the shared SessionStore). But adjusting the distribution of requests among threads will unfortunately not work, as solely the OS decides which incoming connection is handled by which thread (keep-alive connections will stay on the same thread, though).

But I guess having a thread-safe session object will be good enough in most cases. Keep in mind that even on a single thread it will be possible to have high-level race conditions due to multiple "parallel" fibers running, so forcing the same thread per source would not help much there.