Is there a way to protect a piece of critical code?

robert no-spam at no-spam-no-spam.invalid
Thu Jan 11 10:37:06 CET 2007


Hendrik van Rooyen wrote:
> "robert" <no-spam at no-spam-no-spam.invalid> wrote:
> 
>> List .append() and .pop() will be atomic in any Python though its not
> mentioned explicitely - otherwise it would be time to leave Python.
>> There is also Queue.Queue - though it has unneccessary overhead for most
> purposes.
>>
> am aware of Queue module - the same app uses it for something else.
> I dont like too many try -- excepts in the code - I find they confuse
> me when I try to read it later - and in this case I cannot block on waiting for
> the queue to fill.


pushing data objects through an inter-thread queue is a major source for trouble - as this thread shows again.
Everybody builds up a new protocol and worries about Empty/Full, Exception-handling/passing, None-Elements, ...
I've noticed that those troubles disappear when a functional queue is used - which is very easy with a functional language like Python.
For example with http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/491281


One would just use a  cq=CallQueue()

On the producer side one would just write the functional code one wants to execute in a target thread:

cq.call( what_i_want_do_func )


The consumer/receiver thread would just do (periodically) a non-blocking

cq.receive()


=> Without any object fumbling, protocol worries and very fast.

And note: This way - working with functional jobs - one can also "protect a piece of critical code" most naturally and specifically for certain threads without spreading locks throughout the code.
Even things which are commonly claimed "forbidden" (even when using lots of locks) can be magically done in perfect order and effectively this way. Think of worker threads doing things in the GUI or in master / database owner threads etc.

Similarly discrete background thread jobs can be used in a functional style this way:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/491280
( an alternative for the laborious OO-centric threading.Thread which mostly is a lazy copy from Java )
or for higher job frequencies by using "default consumer threads" as also shown in the 1st example of 
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/491281



Robert



More information about the Python-list mailing list