Bryan Olson a écrit :
> Benjamin Watine wrote:
>> [EMAIL PROTECTED] a écrit :
>>> I wrote:
>>>> And here's a thread example, based on Benjamin's code:
>>> [...]
>>>
>>> Doh! Race condition. Make that:
>>>
>>> import subprocess
>>> import thread
>>> import Queue
>>>
>>> def readtoq(pipe, q):
>>> q.put(pipe.read())
>>>
>>> cat = subprocess.Popen('cat', shell=True, stdin=subprocess.PIPE,
>>> stdout=subprocess.PIPE)
>>>
>>> myVar = str(range(1000000)) # arbitrary test data.
>>>
>>> q = Queue.Queue()
>>> thread.start_new_thread(readtoq, (cat.stdout, q))
>>> cat.stdin.write(myVar)
>>> cat.stdin.close()
>>> cat.wait()
>>> myNewVar = q.get()
>>>
>>> assert myNewVar == myVar
>>> print len(myNewVar), "bytes piped around."
>
>> Great, it works, thank you Bryan !
>>
>> Could you explain me why you use a queue instead of a simple array for
>> getting the piped var ?
>
> The call to q.get() will block until an item is in the queue.
> At that point in the program, we had already waited for cat to
> terminate:
>
> cat.wait()
> myNewVar = q.get()
>
> But passing cat.wait() does not imply that our own thread has
> already read all of cat's output and put it in some destination
> object. Data could still be in transit.
>
> My first version, subsequently titled, "Doh! Race condition,"
> worked in all of several runs of its built-in test. Doesn't
> make it right.
>
OK, so if I understand well what you said, using queue allow to be sure
that the data is passed in totality before coninuing with next
instruction. That make sense.
Using thread and queue seems to be very more slow than using files
redirection with bash. I'll see if it make a great load average and/or
I/O time.
Thanks again for your help Bryan.
Ben
--
http://mail.python.org/mailman/listinfo/python-list
