On 2013-10-03, Roy Smith wrote:
> Threads are lighter-weight. That means it's faster to start a new
> thread (compared to starting a new process), and a thread consumes
> fewer system resources than a process.
That's true, but the extent to which it's true varies considerably
from one OS to an
Roy Smith wrote:
> Threads are lighter-weight. That means it's faster to start a new
> thread (compared to starting a new process), and a thread consumes fewer
> system resources than a process. If you have lots of short-lived tasks
> to run, this can be significant. If each task will run for a
On Fri, Oct 4, 2013 at 5:53 AM, Roy Smith wrote:
> So, I think my original statement:
>
>> if you're looking for a short answer, I'd say just keep doing what
>> you're doing using multiple processes and don't get into threading.
>
> is still good advice for somebody who isn't sure they need thread
In article ,
Chris Angelico wrote:
> As to your corrupt data example, though, I'd advocate a very simple
> system of object ownership: as soon as the object has been put on the
> queue, it's "owned" by the recipient and shouldn't be mutated by
> anyone else.
Well, sure. I agree with you that t
On 3/10/2013 12:50, Chris Angelico wrote:
> On Fri, Oct 4, 2013 at 2:41 AM, Roy Smith wrote:
>> The downside to threads is that all of of this sharing makes them much
>> more complicated to use properly. You have to be aware of how all the
>> threads are interacting, and mediate access to shared
On Fri, Oct 4, 2013 at 4:28 AM, Roy Smith wrote:
> Well, the GIL certainly eliminates a whole range of problems, but it's
> still possible to write code that deadlocks. All that's really needed
> is for two threads to try to acquire the same two resources, in
> different orders. I'm running the
In article ,
Chris Angelico wrote:
> On Fri, Oct 4, 2013 at 2:41 AM, Roy Smith wrote:
> > The downside to threads is that all of of this sharing makes them much
> > more complicated to use properly. You have to be aware of how all the
> > threads are interacting, and mediate access to shared r
On Fri, Oct 4, 2013 at 2:41 AM, Roy Smith wrote:
> The downside to threads is that all of of this sharing makes them much
> more complicated to use properly. You have to be aware of how all the
> threads are interacting, and mediate access to shared resources. If you
> do that wrong, you get mem
On Fri, Oct 4, 2013 at 2:01 AM, JL wrote:
> What is the difference between running multiple python scripts and a single
> multi-threaded script? May I know what are the pros and cons of each
> approach? Right now, my preference is to run multiple separate python scripts
> because it is simpler.
In article ,
JL wrote:
> What is the difference between running multiple python scripts and a single
> multi-threaded script? May I know what are the pros and cons of each
> approach? Right now, my preference is to run multiple separate python scripts
> because it is simpler.
First, let's ta
What is the difference between running multiple python scripts and a single
multi-threaded script? May I know what are the pros and cons of each approach?
Right now, my preference is to run multiple separate python scripts because it
is simpler.
--
https://mail.python.org/mailman/listinfo/pytho
11 matches
Mail list logo
