threading

Marko Rauhamaa marko at pacujo.net
Tue Apr 8 01:19:02 EDT 2014


Dennis Lee Bieber <wlfraed at ix.netcom.com>:

> 	That's been my experience too... Threading works for me... My
> attempts at so called asyncio (whatever language) have always led to
> my having to worry about losing data if some handler takes too long to
> return.
>
> 	To me, asyncio is closer to a polling interrupt handler, and I
> still need a thread to handle the main processing.

Yes, asynchronous processing results in complex, event-driven state
machines that can be hard to get right. However, my experience is that
that's the lesser evil.

About a handler taking too long: you need to guard each state with a
timer. Also, you need then to handle the belated handler after the timer
has expired.

The main problems with threads include:

 * Thread-safety is rarely done right. Also, when it's done wrong, it
   can be virtually impossible to fix it without a significant rewrite.
   This is not a theoretical concern: I have had to deal with the
   resulting nightmares in my work.

 * There is no accepted, taught, industry-wide discipline on proper
   thread-safety practices so every developer has to improvise. I have
   come up with a "bullet-proof" way of developing with threads, but
   even that methodology has nasty corner cases.

 * Thread-safety cannot be abstracted out. IOW, divide and conquer
   doesn't work. You can't hide the locking inside a class and forget
   about it. The entire application must be aware low-level thread
   synchronization needs.

 * Threads assume each state has one exit event. At a bare minimum, each
   thread should be prepared to have the blocking event aborted from the
   outside. Unfortunately, most threading frameworks don't allow for
   graceful aborts (that goes for Java and Python, too).

 * If you have made your design around threads and finally decide
   asynchronous processing would have been a better choice, a complete
   rewrite is required if it is even possible. Library writers often
   only provide blocking I/O functions forcing you to insulate the
   libraries in thread pools.


Marko



More information about the Python-list mailing list