threading

[Marko Rauhamaa]

"Frank Millman" <frank at chagford.com>:

> I am finding difficulty in understanding the benefit of going async in
> my case. If most requests require a blocking handler, it seems that I
> might as well stick with each request being handled by a thread,
> independent of all other threads.

When the underlying facilities only provide blocking access, you are
forced to use threads (or processes).

One area where asynchronous programming was always the method of choice
is graphical user interfaces. The GUI of an application must always be
responsive to the user and must be prepared to handle any of numerous
stimuli.

Network protocol layers are also usually implemented asynchronously. The
protocol standards read like asynchronous programs so the translation
into executable programs is most natural in the asynchronous style.
Here, too, the networking entities must be ready for different stimuli
in any state, so threads are usually not a good fit.

Kernel programming makes use of threads and processes. However, the
asynchronous style is there in a big way in the form of interrupt
handlers, hooks and system calls.

Really, the threading model is only good for a relatively small subset
of programming objectives, and over the lifetime of the solution, you
will often come to realize threading wasn't that good a fit after all.
Namely, in any given state, you will have to be prepared to handle more
than one stimulus. Also, over time you will learn to dread the race
conditions that are endemic in thread programming. Those are the kinds
of problems that make you check out the current job postings. Only
there's no escape: in your next job, they are going to make you find and
fix the race conditions in your predecessor's code.


Marko