Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #56713
| Date | 2013-10-12 08:35 +1100 |
|---|---|
| From | Cameron Simpson <cs@zip.com.au> |
| Subject | Re: Multi-threading in Python vs Java |
| References | <l39l00$nb5$1@ger.gmane.org> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.1020.1381527331.18130.python-list@python.org> (permalink) |
On 11Oct2013 15:53, Terry Reedy <tjreedy@udel.edu> wrote: > On 10/11/2013 4:41 AM, Peter Cacioppi wrote: > >I should add that the computational heavy lifting is done in a third party library. So a worker thread looks roughly like this (there is a subtle race condition I'm glossing over). > > > >while len(jobs) : > > job = jobs.pop() > > model = Model(job) # Model is py interface for a lib written in C > > newJobs = model.solve() # This will take a long time > > for each newJob in newJobs : > > jobs.add(newJob) > > > >Here jobs is a thread safe object that is shared across each worker thread. It holds a priority queue of jobs that can be solved in parallel. > > > >Model is a py class that provides the API to a 3rd party library written in C.I know model.solve() will be the bottleneck operation for all but trivial problems. [...] > Given that model.solve takes a 'long time' (seconds, at least), the > extra time to start a process over the time to start a thread will > be inconsequential. I would therefore look at the multiprocessing > module. And, for contrast, I would not. Threads are my friends and Python threads seem eminently suited to the above scenario. Cheers, -- Cameron Simpson <cs@zip.com.au> [Alain] had been looking at his dashboard, and had not seen me, so I ran into him. - Jean Alesi on his qualifying prang at Imola '93
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: Multi-threading in Python vs Java Cameron Simpson <cs@zip.com.au> - 2013-10-12 08:35 +1100
csiph-web