-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Some people wrote: [Threads are a pain, much better to stick to message passing] Some other people wrote: [But but but processes communicating with pipes is the same as threads using message passing primitives] Well, yes. To a certain extent, threads vs. processes is a meanginless distinction; processes can share memory, threads can communicate over pipe-like things. But processes enforce isolation of mutable state unless you explicitly go and share memory. What's at issue here, really, are message passing versus shared- structure programming models. And I concur with Elf and others: message passing is, by far, the better model, since shared structures are a pain to get right. Full disclosure: I've written complex high-performance threaded apps in Java... and ended up splitting them out into separate processes, for the following reasons: 1) They could be easily moved to different machines to cope with increasing load, and communicate over TCP 2) It limited the consequences of a JVM segfaulting (which, also, seemed to happen less the less threads we ran per JVM, creating a rather quadratic increase in system availability) 3) It let me do rolling replacements of parts of the system with new code. Replace each worker process in turn so we're never down more than one. Replacing the old threaded code was "take system down, bring new system up, quickly roll the old .jar back if it doesn't start and run properly" The fact that processes gave us simple control of communication, by making it explicit and preventing threads from accidentally interacting through global variables, would have been a benefit were I not the kind of incredibly elite programmer who actually knows how to write concurrent shared-state code properly *and* the sole developer *and* that I managed to get away with telling the management that I wouldn't work on certain bits of the system without taking a long time to think about it first, regardless of their important business requirements. But this is very much not representative of most development teams... However, they do have some uses - after all, a message queue is a form of shared structure in the first place, and there are uses for a limited set of other *simple* shared structures where the effort of developing the thing to work correctly in all situations is worth it for the performance benefits (guaranteed-unique serial number generators, shared caches, that sort of thing). But definitely in the realm of "concurrent structure programmers produce libraries that the rest of us use". On an orthogonal level, Elf has also pointed out that there are OS- level implications of the choice between threads and processes, regarding signal handling and blocking and so on. But this is a separate issue. If a threaded programming model is what you want by the OS makes it painful to do so, you can always make your app store all its data in a mmaped segment then fork off children then have them mmap in the parent's memory to get the same effect as threads, but with independent signal state and scheduling and so on. ABS - -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/?author=4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkigygUACgkQRgz/WHNxCGpWIACfZ6kRuQ2G7sGRaVp7kqpDpzZD 49EAnjdA6/6euM2tWDD9qePK9cQQan63 =pVAh -----END PGP SIGNATURE----- _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
