Concurrency models (was: Timer)

[Cameron Laird]

In article <mailman.168.1067342457.702.python-list at python.org>,
Anthony Briggs  <abriggs at westnet.com.au> wrote:
			.
			.
			.
>I'll take your word for it. It sounds like a recipe for a lot of hair 
>pulling to me. What happens if there's some part of your code that 
>you don't want interrupted? eg. database commits, file access, any 
>sort of time critical stuff, that sort of thing. Is there a way to 
>switch it off?
			.
			.
			.
Ah!  There's confusion, just the sort that plagues *everyone* 
on his or her first acquaintance with this concurrency model.

If you set an after() timer for, let's say, five seconds, then
launch a big atomic database operation, the database transaction
is NOT interrupted after five seconds.  The five seconds means,
"check on me whenever you get a chance, and, if five seconds 
have elapsed, then wake me up and I'll process for a while."  In
the case at hand, the database transaction starts, and runs 
through to completion, without interruption, even if it requires
*fifty* seconds.  Once it's done (more-or-less, depending on
details of its invocation), the after callback gets its chance.
There's no hazard that needs to be "switched off".

This is how event processing works within a thread.  A simple
program can use both threads and events, but they don't "cross".
-- 

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