On 2008-09-17, Jonathan Cast <[EMAIL PROTECTED]> wrote: > On Wed, 2008-09-17 at 18:40 +0000, Aaron Denney wrote: >> On 2008-09-17, Arnar Birgisson <[EMAIL PROTECTED]> wrote: >> > Hi Manlio and others, >> > >> > On Wed, Sep 17, 2008 at 14:58, Manlio Perillo <[EMAIL PROTECTED]> wrote: >> >>> http://www.heise-online.co.uk/open/Shuttleworth-Python-needs-to-focus-on-future--/news/111534 >> >>> >> >>> "cloud computing, transactional memory and future multicore processors" >> >>> >> >> >> >> Multicore support is already "supported" in Python, if you use >> >> multiprocessing, instead of multithreading. >> > >> > Well, I'm a huge Python fan myself, but multiprocessing is not really >> > a solution as much as it is a workaround. Python as a language has no >> > problem with multithreading and multicore support and has all >> > primitives to do conventional shared-state parallelism. However, the >> > most popular /implementation/ of Python sacrifies this for >> > performance, it has nothing to do with the language itself. >> >> Huh. I see multi-threading as a workaround for expensive processes, >> which can explicitly use shared memory when that makes sense. > > That breaks down when you want 1000s of threads.
This really misses the point I was going for. I don't want 1000s of threads. I don't want *any* threads. Processes are nice because you don't have other threads of execution stomping on your memory-space (except when explicitly invited to by arranged shared-memory areas). It's an easier model to control side-effects in. If this is too expensive, and threads in the same situation will work faster, than I might reluctantly use them instead. > I'm not aware of any program, on any system, that spawns a new process > on each event it wants to handle concurrently; inetd > systems that don't use an existing user-space thread library (such as > Concurrent Haskell or libthread [1]) emulate user-space threads by > keeping a pool of processors and re-using them (e.g., IIUC Apache does > this). Your response seems to be yet another argument that processes are too expensive to be used the same way as threads. In my mind pooling vs new-creation is only relevant to process vs thread in the performance aspects. The fact that people use thread-pools means that they think that even thread-creation is too expensive. The central aspect in my mind is a default share-everything, or default share-nothing. One is much easier to reason about and encourages writing systems that have less shared-memory contention. -- Aaron Denney -><- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe