Threads vs Processes

[bryanjugglercryptographer at yahoo.com]

mark wrote:
> The debate should not be about "threads vs processes", it should be
> about "threads vs events".

We are so lucky as to have both debates.

> Dr. John Ousterhout (creator of Tcl,
> Professor of Comp Sci at UC Berkeley, etc), started a famous debate
> about this 10 years ago with the following simple presentation.
>
> http://home.pacbell.net/ouster/threads.pdf

The Ousterhout school finds multiple lines of execution
unmanageable, while the Tannenbaum school finds asynchronous I/O
unmanageable.

What's so hard about single-line-of-control (SLOC) event-driven
programming? You can't call anything that might block. You have to
initiate the operation, store all the state you'll need in order
to pick up where you left off, then return all the way back to the
event dispatcher.

> That sentiment has largely been ignored and thread usage dominates but,
> if you have been programming for as long as I have, and have used both
> thread based architectures AND event/reactor/callback based
> architectures, then that simple presentation above should ring very
> true. Problem is, young people merely equate newer == better.

Newer? They're both old as the trees. That can't be why the whiz
kids like them. Threads and process rule because of their success.

> On large systems and over time, thread based architectures often tend
> towards chaos.

While large SLOC event-driven systems surely tend to chaos. Why?
Because they *must* be structured around where blocking operations
can happen, and that is not the structure anyone would choose for
clarity, maintainability and general chaos avoidance.

Even the simplest of modular structures, the procedure, gets
broken. Whether you can encapsulate a sequence of operations in a
procedure depends upon whether it might need to do an operation
that could block.

Going farther, consider writing a class supporting overriding of
some method. Easy; we Pythoneers do it all the time; that's what
O.O. inheritance is all about. Now what if the subclass's version
of the method needs to look up external data, and thus might
block? How does a method override arrange for the call chain to
return all the way back to the event loop, and to and pick up
again with the same call chain when the I/O comes in?

> I have seen a few thread based systems where the
> programmers become so frustrated with subtle timing issues etc, and they
> eventually overlay so many mutexes etc, that the implementation becomes
> single threaded in practice anyhow(!), and very inefficient.

While we simply do not see systems as complex as modern DBMS's
written in the SLOC event-driven style.

> BTW, I am fairly new to python but I have seen that the python Twisted
> framework is a good example of the event/reactor design alternative to
> threads. See
>
> http://twistedmatrix.com/projects/core/documentation/howto/async.html .

And consequently, to use Twisted you rewrite all your code as
those 'deferred' things.


-- 
--Bryan