Paul Pittlerson writes:
[...]
> def run(self):
> while True:
>
> sleep(0.1)
>
> if not self.q.empty():
> print self.q.get()
>
> else:
> break
[...]
> This works great on lin
On 6/9/2013 14:27, Paul Pittlerson wrote:
f> Ok here is the fixed and shortened version of my script:
>
> #!/usr/bin/python
>
> from multiprocessing import Process, Queue, current_process
> from threading import Thread
> from time import sleep
>
> class Worker():
> def __init__(self, Que):
>
On Fri, Sep 6, 2013 at 1:27 PM, Paul Pittlerson wrote:
> Ok here is the fixed and shortened version of my script:
Before going any further, I think you need to return to marduk's
response and consider if you really and truly need both threads and
fork (via multiprocessing).
http://www.linuxprogr
Ok here is the fixed and shortened version of my script:
#!/usr/bin/python
from multiprocessing import Process, Queue, current_process
from threading import Thread
from time import sleep
class Worker():
def __init__(self, Que):
self._pid = current_process().pid
self.q
Piet van Oostrum writes:
> def run(self):
> for n in range(5):
> self.que.put('%s tick %d' % (self._pid, n))
> # do some work
> time.sleep(1)
> self.que.put('%s has exited' % self._pid)
To prevent the 'exited' message to disappear if there
Paul Pittlerson writes:
> On Friday, September 6, 2013 1:46:40 AM UTC+3, Chris Angelico wrote:
>
>> The first thing I notice is that your Debugger will quit as soon as
>> its one-secondly poll results in no data. This may or may not be a
>> problem for your code, but I'd classify it as code smell
On Fri, Sep 6, 2013 at 9:34 AM, Paul Pittlerson wrote:
> On Friday, September 6, 2013 1:28:39 AM UTC+3, mar...@python.net wrote:
>
>> Also you can't (and shouldn't) depend on the time that __del__ gets
>> called. It can get called at any time, in any order and sometimes not
>> at all.*
>
> Wow I
On Friday, September 6, 2013 1:46:40 AM UTC+3, Chris Angelico wrote:
> The first thing I notice is that your Debugger will quit as soon as
> its one-secondly poll results in no data. This may or may not be a
> problem for your code, but I'd classify it as code smell at best. Is
> your goal here to
On Friday, September 6, 2013 1:28:39 AM UTC+3, mar...@python.net wrote:
> Also you can't (and shouldn't) depend on the time that __del__ gets
> called. It can get called at any time, in any order and sometimes not
> at all.*
Wow I did not know that! I was counting on that it reliably gets called
On Fri, Sep 6, 2013 at 5:27 AM, Paul Pittlerson wrote:
> I'm trying to understand data handling using multiprocessing and threading,
> haven't gotten very far without running into problems. This is my code:
>
>
> What I expect to happen is the Debugger object will receive one string at a
> time,
On Thu, Sep 5, 2013, at 03:27 PM, Paul Pittlerson wrote:
> I'm trying to understand data handling using multiprocessing and
> threading, haven't gotten very far without running into problems. This is
> my code:
[snip (not sure why you are using multiprocessing and threading at the
same time]
>
I'm trying to understand data handling using multiprocessing and threading,
haven't gotten very far without running into problems. This is my code:
#!/usr/bin/python
from multiprocessing import Process
from multiprocessing import Queue
from multiprocessing import current_process
from threading
12 matches
Mail list logo
