Am 22.07.2015 um 08:49 schrieb Taylor Gronka:

On Tue, 21 Jul 2015 19:48:15 GMT, Sönke Ludwig wrote:

Since the DB driver code is not thread-safe, you'll have to create one CassandraClient instance per thread. In that case everything should work fine in theory. The simplest approach would be to make the Cassandra variables static. However, you'll have to be careful to not introduce any race-conditions in your own code, too, and use a TaskMutex (or normal Mutex) where appropriate.

I was wishing the ConnectionPool code you added would magically make it thread-safe, haha. (You don't have to explain it I'll look up exactly what it does.)

The best that ConnectionPool could reasonably do as it stands would be
to internally create one pool per thread, because individual connections
cannot safely be moved between threads anyway (or at least there is no
static guarantee that a particular connection type is able to handle
that). So it wouldn't really gain anything effectively.

Since the protocol is relatively simple, I'd recommend to extend the cassandra-d driver instead. However, the original author doesn't seem to be active anymore, so this might mean taking the maintainership. Maybe it's possible to contact him and move the driver to a GitHub organization.

I'll do that then. I've liked working with Cassandra, and I've liked working with D and vibe.d. I lack background though so it will take me a bit, but I think I can mostly follow it.

Is the vibe.d newsgroup the best place to follow discussion about the framework (and learn more)?

The newsgroup and also the GitHub repository. A lot of discussions
around implementation or design issues happen there.

At exactly what point are threads spawned at? It seems to me that it's at the point listenHTTP(settings, router);.

Yes, this is the latest point at which they will be started. On a lower
level, it happens when the first worker task is started
(runWorkerTask/runWorkerTaskDist). By default, the number of threads
will equal the number of logical CPU cores and starting more worker
tasks or listening for more HTTP connections will not change the number
of worker threads.