is there enough information?

[castironpi at gmail.com]

On Feb 26, 2:17 pm, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
> On Tue, 26 Feb 2008 10:39:04 -0800 (PST), castiro... at gmail.com 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.