[Python-ideas] easy thread-safety [was: fork]

[Paul Moore]

On 18 August 2015 at 21:32, Sven R. Kunze <srkunze at mail.de> wrote:
> To me, a process/thread or any other concurrency solution, is basically a
> function that I can call but runs in the background. Later, when I am ready,
> I can collect its result. In the meantime, the main thread continues.
> (Again) to me, that is the only sensible way to approach concurrency.

It seems to me that this is accurate, but glosses over all of the
issues that result in multiple solutions being needed. Sure, all
concurrency solutions provide this. But the difference lies in the
environment of the function you're calling. Does it have access to the
same non-local name bindings as it would if run in the foreground? To
the same objects? Is it able to write to those objects safely, or must
it treat them as read only. Or can it write, but only if it follows a
particular protocol (semaphores, locks, etc fit here)?

If you reduce the functionality you're considering to the lowest
common denominator, then all solutions look the same, in essence by
definition (that's basically what lowest common denominator means).
But you haven't actually solved any real-world problems by doing so.

Conversely, it *is* true that a lot of problems that benefit from
concurrency can work with the minimal guarantees of a lowest common
denominator solution (no shared state pure functions). Functional
programming has shown us that. For those problems, any of the options
are fine, and the decision gets made on other factors (most likely
performance, as each solution makes different performance trade-offs
in the process of providing whatever extra guarantees they make).

I'm confused as to what your point is. "People should write concurrent
code in a no shared state pure function manner" seems to be what your
comment "the only sensible way" implies. If so, then fine that's your
opinion, but others differ and Python caters for those people as well.
If, on the other hand, you accept the need for shared state (even if
it's just I/O) then discounting the constraints that such shared state
implies seems either naive or simply wrong. Or I'm missing something,
but I can't see what it is.

Paul