is there enough information?

[Jeff Schwab]

castironpi at gmail.com wrote:
> On Feb 26, 12:04 pm, Jeff Schwab <j... at schwabcenter.com> wrote:
>> castiro... at gmail.com wrote:
>>> On Feb 26, 11:37 am, Jeff Schwab <j... at schwabcenter.com> wrote:
>>>> castiro... at gmail.com wrote:
>>>>> On Feb 26, 10:59 am, Preston  Landers <pland... at gmail.com> wrote:
>>>>>> On Feb 26, 1:45 am, castiro... at gmail.com 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.