On 2008-09-17, Arnar Birgisson <[EMAIL PROTECTED]> wrote: > Hi Aaron, > > On Wed, Sep 17, 2008 at 23:20, Aaron Denney <[EMAIL PROTECTED]> wrote: >> I entered the discussion as which model is a workaround for the other >> -- someone said processes were a workaround for the lack of good >> threading in e.g. standard CPython. I replied that most languages >> thread support can be seen as a workaround for the poor performance >> of communicating processes. (creation in particular is usually >> cited, but that cost can often be reduced by process pools, context >> switching costs, alas, is harder.) > > That someone was probably me, but this is not what I meant. I meant > that the "processing" [1] Python module is a workaround for CPython's > performance problems with threads.
Ah, on rereading that's much clearer. Thank you for the clarification. > The processes vs. threads depends on definitions. There seem to be two > sets floating around here. One is that processes and threads are > essentially the same, the only difference being that processes don't > share memory but threads do. With this view it doesn't really matter > if "processes" are implemented as proper OS processes or OS threads. > Discussion based on this definition can be interesting and one model > fits some problems better than the other and vice versa. > > The other one is the systems view of OS processes vs. OS threads. > Discussion about the difference between these two is only mildly > interesting imo, as I think most people agree on things here and they > are well covered in textbooks that are old as dirt. I think from the OS point of view, these two distinctions are nearly equivalent. There is only a difference when you start talking about non-OS threads, such as those provided by various language runtimes. >> There, the implementation detail of thread, rather than process >> allows and even encourages shortcuts that violate the process model. > > Well, this is a viewpoint I don't totally agree with. Correct me if > I'm not understanding you, but you seem to be making the point that > OS processes are often preferred because with threads, you *can* get > yourself in trouble by using shared memory. That's exactly it. Or rather, you can get in exactly as much trouble with processes, but because accessing a variable in another memory space is more cumbersome, you have to actually think when you do so. Looking at all uses of "a = b" to see what invariants might be broken is unfeasible. Looking at all requests for updating a remote variable might be manageable. -- Aaron Denney -><- _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
