Paul Rubin <>:

> Marko Rauhamaa <> 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

    while True:
        while request.incomplete():
                   # 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.


Reply via email to