Philip Semanchuk wrote:
> The general rule is that it is a lot easier to share data between
> threads than between processes. The multiprocessing library makes the
> latter easier but is only part of the standard library in Python >= 2.6.
> The design of your application matters a lot. For instance
On Feb 17, 2009, at 10:18 AM, Barak, Ron wrote:
I have a wxPython application that builds an internal database from
a list of files and then displays various aspects of that data,
in response to user's requests.
I want to add a module that finds events in a set of log files
(LogManager).
T
Hi,
May I have your recommendations in choosing threads or processes for the
following ?
I have a wxPython application that builds an internal database from a list of
files and then displays various aspects of that data,
in response to user's requests.
I want to add a module that finds events
mark wrote:
> On Wed, 26 Jul 2006 10:54:48 -0700, Carl J. Van Arsdall wrote:
> > Alright, based a on discussion on this mailing list, I've started to
> > wonder, why use threads vs processes.
>
> The debate should not be about "threads vs processes", it
sturlamolden wrote:
> Chance Ginger wrote:
>
> > Not quite that simple. In most modern OS's today there is something
> > called COW - copy on write. What happens is when you fork a process
> > it will make an identical copy. Whenever the forked process does
> > write will it make a copy of the memo
sturlamolden wrote:
> A noteable exception is a toy OS from a manufacturer in Redmond,
> Washington. It does not do COW fork. It does not even fork.
>
> To make a server system scale well on Windows you need to use threads,
> not processes.
Here's one to think about: if you have a bunch of thread
Chance Ginger wrote:
> Not quite that simple. In most modern OS's today there is something
> called COW - copy on write. What happens is when you fork a process
> it will make an identical copy. Whenever the forked process does
> write will it make a copy of the memory. So it isn't quite as bad.
On Thu, 27 Jul 2006 20:53:54 -0700, Nick Vatamaniuc wrote:
> Debugging all those threads should be a project in an of itself.
Ahh, debugging - I forgot to bring that one up in my argument! Thanks
Nick ;)
Certainly I agree of course that there are many applications which suit
a threaded design. I
[mark]
> http://twistedmatrix.com/projects/core/documentation/howto/async.html .
At my work, we started writing a web app using the twisted framework,
but it was somehow too twisted for the developers, so actually they
chose to do threading rather than using twisted's async methods.
--
Tobias Br
"Dennis Lee Bieber" <[EMAIL PROTECTED]> Wrote:
| On Thu, 27 Jul 2006 09:17:56 -0700, "Carl J. Van Arsdall"
| <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
|
| > Ah, alright, I think I understand, so threading works well for sharing
| > python objects. Would a scenario for this
in the same number of lines
having the same or better performance. I bet you'll end up having a
whole bunch of 'locks', 'waits' and 'notify's instead of a bunch of
"those 'deferred' things." Debugging all those threads should be a
project in an o
mark wrote:
> The debate should not be about "threads vs processes", it should be
> about "threads vs events".
We are so lucky as to have both debates.
> Dr. John Ousterhout (creator of Tcl,
> Professor of Comp Sci at UC Berkeley, etc), started a famous debate
&g
On Wed, 26 Jul 2006 10:54:48 -0700, Carl J. Van Arsdall wrote:
> Alright, based a on discussion on this mailing list, I've started to
> wonder, why use threads vs processes.
The debate should not be about "threads vs processes", it should be
about "threads vs events"
[EMAIL PROTECTED] wrote:
> Carl J. Van Arsdall wrote:
> [...]
>
>> I actually do use pickle (not for this, but for other things), could you
>> elaborate on the safety issue?
>>
>
> >From http://docs.python.org/lib/node63.html :
>
> Warning: The pickle module is not intended to be secure
Carl J. Van Arsdall wrote:
[...]
> I actually do use pickle (not for this, but for other things), could you
> elaborate on the safety issue?
>From http://docs.python.org/lib/node63.html :
Warning: The pickle module is not intended to be secure
against erroneous or maliciously constructed
[EMAIL PROTECTED] wrote:
> Carl J. Van Arsdall wrote:
>
>> Ah, alright, I think I understand, so threading works well for sharing
>> python objects. Would a scenario for this be something like a a job
>> queue (say Queue.Queue) for example. This is a situation in which each
>> process/thread n
On 2006-07-27, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> If you're sharing things, I would thread. I would not want to
>> pay the expense of a process.
>
> This is generally a false cost. There are very few
> applications where thread/process startup time is at all a
> fast path,
Even if i
Carl J. Van Arsdall wrote:
> Ah, alright, I think I understand, so threading works well for sharing
> python objects. Would a scenario for this be something like a a job
> queue (say Queue.Queue) for example. This is a situation in which each
> process/thread needs access to the Queue to get the
Nick Craig-Wood wrote:
>
> Here is test prog...
>
Here's a more real-life like program done in both single threaded mode
and multi-threaded mode. You'll need PythonCard to try this. Just to
make the point, you will notice that the core code is identical between
the two (method on_menuFileStart
How do i share memory between processes?"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: John Henry wrote:> If you're sharing things, I would thread. I would not want to pay the> expense of a process.This is generally a false cost. There are very few applications wherethread/process startup time is
John Henry wrote:
> If you're sharing things, I would thread. I would not want to pay the
> expense of a process.
This is generally a false cost. There are very few applications where
thread/process startup time is at all a fast path, and there are
likewise few where the difference in context sw
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > John Henry wrote:
> > > Granted. Threaded program forces you to think and design your
> > > application much more carefully (to avoid race conditions, dead-locks,
> > > ...) but there is nothing inherently *non-robust* about threaded
> > > a
[EMAIL PROTECTED] wrote:
> Carl J. Van Arsdall wrote:
>
>> Alright, based a on discussion on this mailing list, I've started to
>> wonder, why use threads vs processes.
>>
>
> In many cases, you don't have a choice. If your Python program
> is
On 2006-07-26 19:10:14, Carl J. Van Arsdall wrote:
> Ah, alright. So if that's the case, why would you use python threads
> versus spawning processes? If they both point to the same address space
> and python threads can't run concurrently due to the GIL what are they
> good for?
Nothing run
Carl J. Van Arsdall wrote:
> Paul Rubin wrote:
>
>>"Carl J. Van Arsdall" <[EMAIL PROTECTED]> writes:
>>
>>
>>>Processes seem fairly expensive from my research so far. Each fork
>>>copies the entire contents of memory into the new process.
>>>
>>
>>No, you get two processes whose address spa
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Yes, someone can, and that someone might as well be you.
> How long does it take to create and clean up 100 trivial
> processes on your system? How about 100 threads? What
> portion of your user waiting time is that?
Here is test prog...
The resu
[EMAIL PROTECTED] wrote:
> John Henry wrote:
> > Granted. Threaded program forces you to think and design your
> > application much more carefully (to avoid race conditions, dead-locks,
> > ...) but there is nothing inherently *non-robust* about threaded
> > applications.
>
> Indeed. Let's just g
Russell Warren wrote:
> This is something I have a streak of paranoia about (after discovering
> that the current xmlrpclib has some thread safety issues). Is there a
> list maintained anywhere of the modules that are aren't thread safe?
It's much safer to work the other way: assume that librari
John Henry wrote:
> >
> > Carl,
> > OS writers provide much more tools for debugging, tracing, changing
> > the priority of, sand-boxing processes than threads (in general) It
> > *should* be easier to get a process based solution up and running
> > andhave it be more robust, when compared to a th
Carl J. Van Arsdall wrote:
> Alright, based a on discussion on this mailing list, I've started to
> wonder, why use threads vs processes.
In many cases, you don't have a choice. If your Python program
is to run other programs, the others get their own processes.
There's no t
John Henry wrote:
>
>>Carl,
>> OS writers provide much more tools for debugging, tracing, changing
>>the priority of, sand-boxing processes than threads (in general) It
>>*should* be easier to get a process based solution up and running
>>andhave it be more robust, when compared to a threaded sol
On 2006-07-26 21:02:59, John Henry wrote:
> Granted. Threaded program forces you to think and design your
> application much more carefully (to avoid race conditions, dead-locks,
> ...) but there is nothing inherently *non-robust* about threaded
> applications.
You just need to make sure that ev
>
> Carl,
> OS writers provide much more tools for debugging, tracing, changing
> the priority of, sand-boxing processes than threads (in general) It
> *should* be easier to get a process based solution up and running
> andhave it be more robust, when compared to a threaded solution.
>
> - Paddy
Carl J. Van Arsdall wrote:
> Alright, based a on discussion on this mailing list, I've started to
> wonder, why use threads vs processes. So, If I have a system that has a
> large area of shared memory, which would be better? I've been leaning
> towards threads
Oops - minor correction... xmlrpclib is fine (I think/hope). It is
SimpleXMLRPCServer that currently has issues. It uses
thread-unfriendly sys.exc_value and sys.exc_type... this is being
corrected.
--
http://mail.python.org/mailman/listinfo/python-list
Paul Rubin wrote:
> "Carl J. Van Arsdall" <[EMAIL PROTECTED]> writes:
>
>> Processes seem fairly expensive from my research so far. Each fork
>> copies the entire contents of memory into the new process.
>>
>
> No, you get two processes whose address spaces get the data. It's
> done with
> Another issue is the libraries you use. A lot of them aren't
> thread safe. So you need to watch out.
This is something I have a streak of paranoia about (after discovering
that the current xmlrpclib has some thread safety issues). Is there a
list maintained anywhere of the modules that are are
"Carl J. Van Arsdall" <[EMAIL PROTECTED]> writes:
> Processes seem fairly expensive from my research so far. Each fork
> copies the entire contents of memory into the new process.
No, you get two processes whose address spaces get the data. It's
done with the virtual memory hardware. The data i
Chance Ginger wrote:
> On Wed, 26 Jul 2006 10:54:48 -0700, Carl J. Van Arsdall wrote:
>
> > Alright, based a on discussion on this mailing list, I've started to
> > wonder, why use threads vs processes. So, If I have a system that has a
> > large area of shared
On Wed, 26 Jul 2006 10:54:48 -0700, Carl J. Van Arsdall wrote:
> Alright, based a on discussion on this mailing list, I've started to
> wonder, why use threads vs processes. So, If I have a system that has a
> large area of shared memory, which would be better? I've been
Alright, based a on discussion on this mailing list, I've started to
wonder, why use threads vs processes. So, If I have a system that has a
large area of shared memory, which would be better? I've been leaning
towards threads, I'm going to say why.
Processes seem fairly ex
41 matches
Mail list logo
