Paul Rubin <no.email@nospam.invalid>: > Marko Rauhamaa <ma...@pacujo.net> writes: >> - Thread programming assumes each thread is waiting for precisely >> one external stimulus in any given state -- in practice, each >> state must be prepared to handle quite a few possible stimuli. > > Eh? Threads typically have their own event loop dispatching various > kinds of stimuli.
I have yet to see that in practice. The "typical" thread works as follows: while True: while request.incomplete(): request.read() # block sql_stmt = request.process() db.act(sql_stmt) # block db.commit() # block response = request.ok_response() while response.incomplete(): response.write() # block The places marked with the "block" comment are states with only one valid input stimulus. > Have threads communicate by message passing with immutable data in the > messages, and things tend to work pretty straightforwardly. Again, I have yet to see that in practice. It is more common, and naturally enforced, with multiprocessing. > Having dealt with some node.js programs and the nest of callbacks they > morph into as the application gets more complicated, threads have > their advantages. If threads simplify an asynchronous application, that is generally done by oversimplifying and reducing functionality. Yes, a "nest of callbacks" can get messy very quickly. That is why you need to be very explicit with your states. Your class needs to have a state field named "state" with clearly named state values. Marko -- https://mail.python.org/mailman/listinfo/python-list