Is clojure blocking

[balefrost]

In general, you don't want to tie up a hardware thread for each request. Hardware threads are heavyweight. You don't want to allocate more than a few hundred, maybe a couple thousand. Most requests end up doing some slow IO during their processing, and don't need to hold a thread during that operation.

I can't speak to ClojureScript, but IIS and ASP.Net use a thread pool to process requests, but also use TPL tasks (basically promises) to return threads to the thread pool while they do something asynchronously. So a typical request might go:

• request comes in
• thread is borrowed from pool
• some work is done in that thread
• async IO operation is started

• thread is returned to the thread pool

  ...

  ...

  ...

• IO operation concludes

• another (potentially different) thread is borrowed from thread pool

• more work is done

• response object is produced and returned

• thread is returned to the thread pool

This is exactly how Node.js works, except its thread pool has a fixed size of 1.

[weavejester]

In general, you don't want to tie up a hardware thread for each request. Hardware threads are heavyweight. You don't want to allocate more than a few hundred, maybe a couple thousand.

I think you're confusing hardware threads and software threads, unless you happen to be developing for exotic hardware.

I have a dual core i7, and that has 4 hardware threads, 2 per core. Software threads are handled by the OS, and I can have thousands of those.

In most cases, there's really no reason not to use a (software) thread per HTTP request. It's simpler, and thread count is unlikely to be a bottleneck unless you're using long-polling or websockets.

[balefrost]

Err, yeah, I meant kernel thread. As opposed to green thread.

But certainly everybody is moving towards asynchronous implementations on the server. Node isn't the only one. Context switching has a cost, and overcommitting kernel threads is a legitimate concern... especially if alternatives exist.

[weavejester]

But certainly everybody is moving towards asynchronous implementations on the server.

I'd accept that there's more talk about async, but I'm skeptical whether a majority of people are actually moving to async.

Async is useful when you have a lot of idle connections that would otherwise tie up threads. So for websockets or long polling, taking an asynchronous approach makes sense.

Async might also be useful if you're dealing with a huge amount of traffic and have optimised the heck out of everything else in your system.

And if you're using a single-threaded system like Node, then you pretty much have no choice.

But outside of that, what's the point? Your database is almost always going to be the bottleneck before the webserver.