On Wed, 03 Jul 2013 09:49:56 GMT, Sönke Ludwig wrote:

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).

I have no objections against the fact that it will be convenient and type-safe. My point is that any global synchronized access is an enormous performance killer comparing to "all thread-local" scenario when it comes to high concurrency models. Making it default may limit any further options. Not sure if result is worth the change.

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).

Well, keep-alive connections are technically the same and one connection, so no wonders here :) I guess I need to study some docs on UNIX sockets to see if that can be controlled on OS level. What I am trying to do here is to create simple end-user guidelines regarding concurrency architecture that will scale flawlessly for typical simple web apps while still allowing developer to use one of most seductive vibe.d features - great performance with minimal efforts.

Unfortunately, my earlier experience with this type of services is about kernel mode processing where one can have full control about whole network stack and scheduling - still having lot of difficulties connecting that experience with user space environment :(

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.

I was quite sure that race conditions can never happen between fibers within one thread as contexts for those get switched only in certain predefined places (usually after registering an event for async I/O operation). Am I wrong?