On Feb 26, 12:37 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > On Feb 26, 12:04 pm, Jeff Schwab <[EMAIL PROTECTED]> wrote: > >> [EMAIL PROTECTED] wrote: > >>> On Feb 26, 11:37 am, Jeff Schwab <[EMAIL PROTECTED]> wrote: > >>>> [EMAIL PROTECTED] wrote: > >>>>> On Feb 26, 10:59 am, Preston Landers <[EMAIL PROTECTED]> wrote: > >>>>>> On Feb 26, 1:45 am, [EMAIL PROTECTED] wrote: > >>>>>>> Two options occurred to me, which the first showed up in the earlier > >>>>>>> extremely skeletal and cryptic post: > >>>>>> Perhaps you would be more likely to get the kind of help you seem to > >>>>>> want > >>>>>> if you refrained from posting "cryptic and skeletal" messages. The > >>>>>> fact that many > >>>>>> other people have pointed this out to you as of late would tend to > >>>>>> suggest > >>>>>> you are trolling, i.e. intentionally trying to foster miscommunication > >>>>>> and threads > >>>>>> that do nothing to advance anyones understanding. > >>>>>> And regarding your other recent post about trying to find a "solution" > >>>>>> to the "problem" > >>>>>> of immutable types... Due to the above reasons you are unlikely to > >>>>>> influence the > >>>>>> design of the core language with half-baked stream of consciousness > >>>>>> ramblings. These > >>>>>> belong in your LiveJournal, not in c.l.python. > >>>>>> If you have a problem you need help with, please read this entire > >>>>>> document about 3 times > >>>>>> before posting anything else: > >>>>>>http://catb.org/~esr/faqs/smart-questions.html > >>>>>> Specifically this: > >>>>>>http://catb.org/~esr/faqs/smart-questions.html#beprecise > >>>>>> and this: > >>>>>>http://catb.org/~esr/faqs/smart-questions.html#goal > >>>>> Ugh, very well. You call for an explanation. > >>>>> Back home, the original post would be interesting, so I wrote it. > >>>>> Whatever reactions other people have to them is information that is > >>>>> unavailable to me. I don't know you. I'm rather irked by a > >>>>> proportion of posts, but for my part, it's hard to get me to point a > >>>>> finger. > >>>>> I am not a troll. I want a sustainable, healthy, productive, > >>>>> educational, informative relationship with frequenters of c.l.p, the > >>>>> Python community at large, and anyone who has anything non-negative to > >>>>> contribute. If you are wanting to see how I react to hostility, just > >>>>> ask. I'll fake it for you, but only for a second at a time. > >>>> Wow. I sure hope I don't come across like castiron does here. > >>>>> Now, what help is it that you believe I seem to want? All I asked for > >>>>> was, ideas. > >>>> It's a little difficult for me to interpret your code, partly because I > >>>> am nbt very familiar with Python's support for concurrency. But what > >>>> are you trying to a achieve? > >>>> You mentioned: "I recently ran into a case (* would that be helpful to > >>>> describe here?) where thread1 had to do something, thread2 had to do > >>>> something after that, and thread1 had to wait for that, then do > >>>> something else, and thread2 again had to wait before starting the first > >>>> thing again." > >>>> This is ordinarily called a Producer-Consumer model. It is often > >>>> implemented using semaphores. Googling "python semaphore" turns up this > >>>> documentation: > >>>>http://www.python.org/doc/lib/semaphore-objects.html > >>>> That page, in turn, links to an example of the proper use of semaphores > >>>> in Python. Does that help?- Hide quoted text - > >>>> - Show quoted text - > >>> Hi Jeff. I've enjoyed your recent posts. > >>> I'm not quite sure a semaphore is exactly the synchronization object > >>> I'm looking for, but I'm a little new to concurrency myself. > >>> In the interface I design, only one with-call can get the result at > >>> once. It was my understanding that semaphores, and many other synch. > >>> objs. returned control at random. > >> I take this to mean that your interface offers a function returns > >> immediately, rather than waiting for the work to complete. Is that > >> correct? > > >>> In fact, in the background, I'm working on something a little more > >>> substantial than this, but it's not done, so the only review of it I > >>> can perform is of its interface. > >> The interface is (in my opinion) usually the best place to start the > >> code, anyway. > > >>> If someone has a "yes, but in half the lines, at twice the speed," > >>> then tear my posts to shreds. > >> It is not quite clear what your code is intended to do. That doesn't > >> mean there's necessarily anything wrong with it, but it's hard for most > >> Usenetters to take the time to read such long sequences of code. Would > >> it be possible for you to post a complete program, that we can actually > >> run? Wherever your code is not yet ready, just put a line or two of > >> "stub" code, and add a comment to explain what should be happening.- Hide > >> quoted text - > > >> - Show quoted text - > > > Sure. And honestly, I have no idea what the best way to go about this > > is, except keep trying. > > > th1 th2 > > set cmd > > run cmd > > get result > > acknowledge > > continue continue > > > th2 won't -run cmd- until th1 completes -set cmd-. th1 won't -get > > result- until th2 completes -run cmd-. and once -acknowledge- > > completes, both can go about their merry ways. > > That is exactly the kind of case where semaphores are usually used. > Thread1 can "fill" the semaphore when the command is ready, then Thread2 > can "empty" the semaphore once it has finished running the command. > > > In the example last > > night, th2 continued to loop to handle requests in a collection of > > threads, but th1 had pressing business elsewhere. > > No problem. It should be waiting on a semaphore, though, not just > "hot-looping." (I am amused by the idea of a thread having pressing > business elsewhere.) > > > Dated 05:07 PST, the code should be runnable. But the only thing is, > > I developed it in Python 3.0a2. In particular, line 71 def > > thloop( thd ), and line 82 def op100( thd ), should demonstrate that > > interface. > > Sorry, I am still having some trouble following it. :-( Maybe somebody > else here is also trying 3.0 already.- Hide quoted text - > > - Show quoted text -
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 I don't see how semaphores could prevent thd.step[2] and thd.step[1] from taking turns in the wrong order. Polling is bad. -- http://mail.python.org/mailman/listinfo/python-list