Concurrency models (was: Timer)

[Cameron Laird]

In article <mailman.132.1067262731.702.python-list at python.org>,
Anthony Briggs  <abriggs at westnet.com.au> wrote:
			.
			.
			.
>>after 5000 { set disabled 0 }
>>
>>The script carries on, and after 5 seconds whatever is being done gets
>>interrupted in order to run a bit of script - in this case set a variable
>>turning off a disablement of some sort.
>
>Wow, that must make your scripts so much more interesting to debug ;)
			.
			.
			.
You probably think you wrote something uncontroversial.
I take this question rather seriously, as it turns out.

Scripts that are "easy to debug" make for an apt focus.
This thread is really about asynchronous or concurrent
processing, I claim, and I further claim we really don't
have *any* satisfying model for coding those.  Threading
is a quagmire (everyone agree?), and our guild has demon-
strated only marginally more reliability in working with,
say, co-routines, chords, continuations, and so on.  For
my money, the event-oriented model behind the [after]
above is at least as robust as any other.

Among other frailties, I hold a grudge against the aca-
demic world that it hasn't shown more leadership in this
matter.

I'll summarize:  validation of event-oriented designs 
implemented with [after] and similar mechanisms, is at
worst no more difficult than validation of the corre-
sponding thread-based designs.  Concurrency is hard to
get right, at least with our current understanding.
-- 

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net