> Under heavy load, this can be quite costly, especially if each request > requires non-trivial processing (ie, enough to make time-slicing kick > in).
This doesn't really jive with reality as far as I can tell; if anything it is the exact opposite of reality. If you're doing significant work in between doing I/O calls (which tend to be context switching points) even to the point of usually yielding only to pre-emptive switching resulting from exceeding your time slice, the relative overhead of threading should be much less (usually) than if you're just doing a huge amount of very very small requests. Whatever the extra cost is in a thread context switch compared to an application context switch (and make no mistake, it's effectively still a context switch; just because you're not switching threads doesn't mean that different requests will not need to e.g. touch differens cache lines, etc), that becomes more relevant as the amount of work done after each switch decreases. The cost of time slicing while holding a lock is real, but if you have a code path with a high rate of lock acquisition in some kind of performance critical situation, presumably you're holding locks for very short periods of time and the likelyhood of switching away at exactly the wrong moment is not very high. Also: Remember that syscalls are most definitely not cheap, and an asynchronous model doesn't save you from doing syscalls for the I/O. > So, between memory overheads, cost of creating and destroying threads > and context switching, using a synchronous model can be extremely > heavyweight compared to an asynchronous model. Its no surprise that > people are seeing much better throughput with asynchronous servers. In my experience threading works quite well for many production tasks, though not all (until we get better "vertical" (all the way from the language to the bare metal) support for cheaper threads). The maintenance and development costs associated with writing complex software in callback form with all state explicitly managed, disabling any use of sensible control flow, exceptions, etc, is very easy to under-estimate in my opinion. It also makes every single call you ever make have part of it's public interface whether or not it *might* do I/O, which is one particular aspect I really dislike other than the callback orientation. You also need to consider latency. While some flawed benchmarks where people throw some fixed concurrency at a problem will show that latency is poor with a threaded model in comparison to an asynch model; under an actual reasonable load where the rate of incoming requests is not infinitely high, the fact that you're doing pre-emption and scheduling across multiple CPU:s will mean that individual expensive requests don't cause multiple other smaller requests to have to wait for it to complete it's bit of work. So again, for CPU-heavy tasks, this is another way in which a threaded model can be better unless you very carefully control the amount of work done in each reactor loop (presuming reactor pattern) in the asynchronous case. As far as I can tell, the advantages from an asynchronous model mostly come in cases where you either (1) have very high concurrency or (2) are doing very very little work for each unit of I/O done, such that the cost of context switching is at it's most significant. My wet dream is to be able to utilize something like Clojure (or anything other than callback/state machine based models) on top of an implementation where the underlying concurrency abstraction is in fact really efficient (in terms of stack sizes and in terms of switching overhead). In other words, the day where having a few hundred thousand concurrents connections does *not* imply that you must write your entire application to be event based, is when I am extremely happy ;) -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
