Alaric Snell-Pym scripsit: > Sometimes, you need threads; the case that comes to mind is a server > that handles lots of connections initiated by clients we have no > control over. If the protocol has any connection state, it's nice to > model that with flow control by having a thread per connection.
It's even nicer to model it with a process per connection, or a thread that's arranged to be shared-nothing (which is what processes really are; threads that share nothing except by arrangement in advance). If processes aren't fast enough, kick the kernel people until they are. (Linux is getting awfully good at fast context-switching FWIU.) > Of course, many high performance servers these days do magic with few > threads and non-blocking I/O to multiplex stuff; at a terrible cost in > ease of understanding their code, which has to be recast as a state > machine so the flow of control can be abstracted out. I agree. Inverted control is disgusting, and there's no reason to use it, *especially* in Scheme where the compiler is supposed to do the work for you! > Erlang FTW. +1 -- But that, he realized, was a foolish John Cowan thought; as no one knew better than he [email protected] that the Wall had no other side. http://www.ccil.org/~cowan --Arthur C. Clarke, "The Wall of Darkness" _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
