threading

[Marko Rauhamaa]

Sturla Molden <sturla.molden at gmail.com>:

> The problem here is the belief that "thread-safety cannot be
> abstracted out". It can. The solution is to share nothing and send
> messages through queues. If you start to use mutexes and conditions
> all over your code, you might shoot yourself in the foot, eventually.

Queues are fine if you hermetically insulate your objects. IOW, you
group your objects in single-threaded pseudoprocesses that don't make
any direct method calls to each other. If you do that, you might as well
use real processes. That way, you can even naturally enforce your
insulation assumption against accidents.

In "normal" multithreaded code, different object methods are called from
different threads. And, as you say, you *will* shoot yourself in the
foot.

Now, even in your queued thread world, you will suffer from the fact
that the naive thread programmer uses blocking function calls (as they
have been taught). Imagine, for example, a network outage in the middle
of a database call. The thread might not take a peek at its input queue
during the stuck I/O call and the application cannot abort the
operation. The solution is to use an asyncio main loop and nonblocking
I/O in each of your insulated threads...


Marko