On Sat, Apr 23, 2011 at 8:13 PM, Mike Meyer <m...@mired.org> wrote: > On Sat, 23 Apr 2011 19:41:28 -0400 > Ken Wesson <kwess...@gmail.com> wrote: >> > Well, Java servers probably are yes, but traditional Unix servers >> > would normally fork a new process for each incoming connection. >> >> Poor man's threads. Although the insulation of each one against >> crashes in the others might be useful when you're coding in a language >> with memory management tools as primitive as C's. ;) > > Or your tools for handling concurrency are as poor as C's (which is > unfortunately most popular languages)
But not Clojure. > or you live in a universe where cosmic rays can flip bits and other > sources of hardware hiccups exist. Software crashes caused by non-software-bug-triggered memory corruption seem to me to be exceedingly rare, and they could as easily strike critical parts of the operating system as a multithreaded server program (and a large batch of independent C jobs will occupy more memory and have a correspondingly larger cross section as a target for such things). The best recourse if the server gets hit by something like that is going to be to reboot it. >> > starting a pool of processes to avoid the startup time of a new process >> > when a new client connects. >> >> With small lightweight C processes and some suitable system for IPC, >> this can work. With JVMs, not so much, unless you have RAM coming out >> of your ears. JVM processes tend to be fairly large; it wouldn't take >> many 64MB java.exe jobs to start the pagefile thrashing. Even with an >> 8GB server, you start paging at 128 simultaneous connections in that >> case, and you certainly can't handle thousands. > > I would have expected large chunks of the JVM processes to be shared > between parent and child - especially before the first accept > returns. That happens forking C programs. It won't happen starting up separate, independent JVM processes, and I don't know how a JVM will handle it if a native method calls fork() but I somehow doubt it will all just work peachily. > In particular, the VM implementation and the compiled JVM > bytecodes should all be shared. Data structures & JIT'ed code - well, > it will depend on a variety of implementation details, but they all > start on shared pages with a COW bit set. Again, that presumes you manage to call fork() and the JVM doesn't bat an eye at being duplicated in mid-execution in that manner. Separately-started JVM processes won't have that parent-child relationship. > Of course, if you're using threads in the parent for other things, > then forking to create new processes creates a bunch of interesting > things to deal with. If you ask me, fork() is a dinosaur, a relic of the C age and indeed of the time before pthreads. -- 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
