Am 28.06.2013 23:14, schrieb Dicebot:

Quiting http://vibed.org/api/vibe.http.session/MemorySessionStore

If the server is running as a single instance (no thread or process clustering), this kind of session store provies the fastest and simplest way to store sessions. In any other case, a persistent session store based on a database is necessary.

Is my understanding correct - HTTP server does not do any locking when interacting with MemorySessionStore and basically the only way to get it with a multiple worker threads is to make similar implementation with mutex securing every method call? What is the general policy in vibe.d server code for global mutable entities?

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.