[EMAIL PROTECTED] wrote: > 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.
I'll try to take a closer look at this a little later. It will be a good chance to learn Python's semaphore interface. However, I am getting the feeling you may have to solve this one on your own. :( -- http://mail.python.org/mailman/listinfo/python-list
