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