[Haskell-cafe] Re: Python's big challenges, Haskell's big advantages?

On 2008-09-17, Arnar Birgisson wrote:

Hi Aaron,

On Wed, Sep 17, 2008 at 23:20, Aaron Denney 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 -><-