On Feb 26, 2:17 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Feb 2008 10:39:04 -0800 (PST), [EMAIL PROTECTED] declaimed
> the following in comp.lang.python:
> > The relevant snippet is:
>
> > def thloop( thd ):
> > while thd.cont:
> > with thd.step[1]:
> > if not thd.cont: break
> > print( 'step 1', end= ' ' )
> > thd.ret= thd.cmd+ 1
> > with thd.step[3]:
> > print( 'step 3' )
> > thd.ret= None
> > thd.step.complete()
>
> > def op100( thd ):
> > with thd.step[0]:
> > print( 'step 0', end= ' ' )
> > thd.cmd= 100
> > with thd.step[2]:
> > print( 'step 2', end= ' ' )
> > ret1= thd.ret
> > assert ret1== 101
>
> Show us the code for "thd" -- we have no idea of where thd.cont is
> set... And how is "thd.step[x]" -- a list object, suddenly converted to
> some other component object with a "thd.step.complete"?
>
> The major thing I get out of this is that your "threads", which
> should have a complete process sequence /within/ them, are being passed
> around to a pair of functions which are trying to control the inner
> workings of the threads. Where are op100 and thloop invoked? In separate
> threads? Then why is the parameter called "thd".
>
> Which is, it seems, totally backwards... Also... to my knowledge,
> the "with" construct (I'm still on Python 2.4 and don't have "with") is
> NOT the same thing as a Java "Synchronized" object. The common use of
> "with" is with objects, like files, that are opened at the start of the
> block, and need to be closed on block exit, regardless of how the block
> is exited.
>
> with something as open(fid): #syntax may be off
> do stuff that may raise an exception
>
> is
>
> something = open(fid)
> try:
> do stuff that may raise an exception
> something.close()
> except blah-blah-blah:
> something.close()
> raise
>
> Old comp.sci. theory => google "communicating sequential processes"
OOo-- good questions-- rare treat.
I invented the idiom of passing a thread object to an execution
routine: sort of a midpoint between subclassing Thread and
threads.start_new_thread. Come to think of it, if you rewrite:
def thloop( self ):
while self.cont:
with self.step[1]:
if not self.cont: break
print( 'step 1', end= ' ' )
self.ret= self.cmd+ 1
with self.step[3]:
print( 'step 3' )
self.ret= None
self.step.complete()
def op100( thd ):
with self.step[0]:
print( 'step 0', end= ' ' )
self.cmd= 100
with self.step[2]:
print( 'step 2', end= ' ' )
ret1= self.ret
assert ret1== 101
The Step class overloads the __getitem__ operator to enable sequence-
step specification. It also has a 'finalize'/'quit'/'open' method
(the latter of which is a somewhat counterintuitive name) to signal
that the thread is terminated, and any threads waiting for step[n] can
look the other way.
You raise a good point too:
> should have a complete process sequence /within/ them, are being
Yes. Can you join these and respawn? Which makes more sense in the
situation?
I am exploring some possibilities for concurrency that Python
"availableizes," Lewis and Clark-style. Are you the frontier?
<grunts, guestures toward self> ME Tarzan.
In another language, you could write:
syncrostep.stepacq( 1 )
self.ret= self.cmd+ 1
syncrostep.release( 1 )
and
steplock= syncrostep.stepacq( 1 )
self.ret= self.cmd+ 1
steplock.release()
> But I
> don't see multiple threads in your sample code.
There are.
The SyncroStep class abstracts an array of semaphores with 'value' =
1, in other words, locks.
At the very least, it's a cool abstraction, even if thdA.haltjoin()/
thdB.haltandjoin()/ store.ret= store.cmd+ 1/ restart( thdA )/
restart( thdB ) or further is always better, and even if I forget what
threads were good for anyway.
--
http://mail.python.org/mailman/listinfo/python-list
