Sturla Molden <sturla.mol...@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 -- https://mail.python.org/mailman/listinfo/python-list
