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
