On Nov 5, 5:09 pm, Paul Boddie [EMAIL PROTECTED] wrote:
Anyway, to keep things constructive, I should ask (again) whether you
looked at tinypy [1] and whether that might possibly satisfy your
embedded requirements.
Actually, I'm starting to get into the tinypy codebase and have been
talking
On Nov 6, 8:25 am, sturlamolden [EMAIL PROTECTED] wrote:
On Nov 5, 8:44 pm, Andy O'Meara [EMAIL PROTECTED] wrote:
In a few earlier posts, I went into details what's meant there:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/...
All this says is:
1. The cost of
On Nov 6, 9:02 pm, sturlamolden [EMAIL PROTECTED] wrote:
On Nov 7, 12:22 am, Walter Overby [EMAIL PROTECTED] wrote:
I read Andy to stipulate that the pipe needs to transmit hundreds of
megs of data and/or thousands of data structure instances. I doubt
he'd be happy with memcpy either. My
On 7 Nov, 03:02, sturlamolden [EMAIL PROTECTED] wrote:
On Nov 7, 12:22 am, Walter Overby [EMAIL PROTECTED] wrote:
I read Andy to stipulate that the pipe needs to transmit hundreds of
megs of data and/or thousands of data structure instances. I doubt
he'd be happy with memcpy either. My
On Nov 7, 11:46 am, Paul Boddie [EMAIL PROTECTED] wrote:
As far as I can tell, he wants to keep the data in one place and just
pass a pointer around between execution contexts.
This would be the easiest solution if Python were designed to do this
from the beginning. I have previously stated
On Nov 4, 6:51 pm, Paul Boddie [EMAIL PROTECTED] wrote:
The language features look a lot like what others have already been
offering for a while: keywords for parallelised constructs (clik_for)
which are employed by solutions for various languages (C# and various C
++ libraries spring
On Nov 5, 8:44 pm, Andy O'Meara [EMAIL PROTECTED] wrote:
In a few earlier posts, I went into details what's meant there:
Hi,
I've been following this discussion, and although I'm not nearly the
Python expert that others on this thread are, I think I understand
Andy's point of view. His premises seem to include at least:
1. His Python code does not control the creation of the threads. That
is done at the app
On Nov 6, 6:05 pm, Walter Overby [EMAIL PROTECTED] wrote:
I don't understand how this would help. If these large data
structures reside only in one remote process, then the overhead of
proxying the data into another process for manipulation requires too
much IPC, or at least so Andy
On Nov 6, 2:03 pm, sturlamolden [EMAIL PROTECTED] wrote:
On Nov 6, 6:05 pm, Walter Overby [EMAIL PROTECTED] wrote:
I don't understand how this would help. If these large data
structures reside only in one remote process, then the overhead of
proxying the data into another process for
On Nov 7, 12:22 am, Walter Overby [EMAIL PROTECTED] wrote:
I read Andy to stipulate that the pipe needs to transmit hundreds of
megs of data and/or thousands of data structure instances. I doubt
he'd be happy with memcpy either. My instinct is that contention for
a lock could be the quicker
On Nov 4, 10:59 am, sturlamolden [EMAIL PROTECTED] wrote:
On Nov 4, 4:27 pm, Andy O'Meara [EMAIL PROTECTED] wrote:
People
in the scientific and academic communities have to understand that the
dynamics in commercial software are can be *very* different needs and
have to show some
On 5 Nov, 20:44, Andy O'Meara [EMAIL PROTECTED] wrote:
On Nov 4, 10:59 am, sturlamolden [EMAIL PROTECTED] wrote:
For Christ sake, researchers
write global climate models using MPI. And you think a toy problem
like 'real-time video processing' is a show stopper for using multiple
On Nov 3, 7:11 pm, Andy O'Meara [EMAIL PROTECTED] wrote:
My hope was that the increasing interest and value associated with
flexible, multi-core/free-thread support is at a point where there's
a critical mass of CPython developer interest (as indicated by various
serious projects specifically
If you are serious about multicore programming, take a look at:
http://www.cilk.com/
Now if we could make Python do something like that, people would
perhaps start to think about writing Python programs for more than one
processor.
--
http://mail.python.org/mailman/listinfo/python-list
On Nov 4, 9:38 am, sturlamolden [EMAIL PROTECTED] wrote:
First let me say that there are several solutions to the multicore
problem. Multiple independendent interpreters embedded in a process is
one possibility, but not the only.''
No one is disagrees there. However, motivation of this
On Nov 4, 4:27 pm, Andy O'Meara [EMAIL PROTECTED] wrote:
People
in the scientific and academic communities have to understand that the
dynamics in commercial software are can be *very* different needs and
have to show some open-mindedness there.
You are beware that BDFL's employer is a
On 4 Nov, 16:00, sturlamolden [EMAIL PROTECTED] wrote:
If you are serious about multicore programming, take a look at:
http://www.cilk.com/
Now if we could make Python do something like that, people would
perhaps start to think about writing Python programs for more than one
processor.
The
On Oct 30, 6:39 pm, Terry Reedy [EMAIL PROTECTED] wrote:
Their professor is Lars Bak, the lead architect of the Google
V8Javascriptengine. They spent some time working on V8 in the last couple
months.
then they will be at home with pyv8 - which is a combination of the
pyjamas
On Oct 30, 11:09 pm, alex23 [EMAIL PROTECTED] wrote:
On Oct 31, 2:05 am, Andy O'Meara [EMAIL PROTECTED] wrote:
I don't follow you there. If you're referring to multiprocessing, our
concerns are:
- Maturity (am I willing to tell my partners and employees that I'm
betting our future on a
Patrick Stinson wrote:
Speaking of the big picture, is this how it normally works when
someone says Here's some code and a problem and I'm willing to pay
for a solution?
In an open-source volunteer context, time is generally more
valuable than money. Most people can't just drop part of
their
Okay, here's the bottom line:
* This is not about the GIL. This is about *completely* isolated
interpreters; most of the time when we want to remove the GIL we want
a single interpreter with lots of shared data.
* Your use case, although not common, is not extraordinarily rare
either.
On Wed, Oct 29, 2008 at 8:05 PM, Glenn Linderman [EMAIL PROTECTED] wrote:
On approximately 10/29/2008 3:45 PM, came the following characters from the
keyboard of Patrick Stinson:
If you are dealing with lots of data like in video or sound editing,
you would just keep the data in shared memory
On Oct 28, 6:11 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
Because then we're back into the GIL not permitting threads efficient
core use on CPU bound scripts running on other threads (when they
otherwise could).
Why do you think so? For C code that is carefully written, the GIL
allows
On Thu, Oct 30, 2008 at 12:05 PM, Andy O'Meara [EMAIL PROTECTED] wrote:
On Oct 28, 6:11 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
Because then we're back into the GIL not permitting threads efficient
core use on CPU bound scripts running on other threads (when they
otherwise could).
Jesse Noller wrote:
Even luminaries such as Brian Goetz and many, many others have pointed
out that threading, as it exists today is fundamentally difficult to
get right. Ergo the renaissance (read: echo chamber) towards
Erlang-style concurrency.
I think this is slightly missing what Andy is
On Oct 30, 1:00 pm, Jesse Noller [EMAIL PROTECTED] wrote:
Multiprocessing is written in C, so as for the less agile - I don't
see how it's any less agile then what you've talked about.
Sorry for not being more specific there, but by less agile I meant
that an app's codebase is less agile if
On Thu, Oct 30, 2008 at 1:54 PM, Andy O'Meara [EMAIL PROTECTED] wrote:
On Oct 30, 1:00 pm, Jesse Noller [EMAIL PROTECTED] wrote:
Multiprocessing is written in C, so as for the less agile - I don't
see how it's any less agile then what you've talked about.
Sorry for not being more specific
On 30 Okt, 14:12, Andy O'Meara [EMAIL PROTECTED] wrote:
3) Start a new python implementation, let's call it CPythonES
[...]
4) Drop python, switch to Lua.
Have you looked at tinypy? I'm not sure about the concurrency aspects
of the implementation, but the developers are not completely
Andy O'Meara wrote:
On Oct 28, 6:11 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
You should really reconsider writing performance-critical code in
Python.
I don't follow you there... Performance-critical code in Python??
Martin meant what he said better later
Again, if you do
Why do you think so? For C code that is carefully written, the GIL
allows *very well* to write CPU bound scripts running on other threads.
(please do get back to Jesse's original remark in case you have lost
the thread :-)
I don't follow you there. If you're referring to multiprocessing
On Wed, Oct 29, 2008 at 4:05 PM, Glenn Linderman [EMAIL PROTECTED] wrote:
On approximately 10/29/2008 3:45 PM, came the following characters from the
keyboard of Patrick Stinson:
If you are dealing with lots of data like in video or sound editing,
you would just keep the data in shared memory
On approximately 10/30/2008 6:26 AM, came the following characters from
the keyboard of Jesse Noller:
On Wed, Oct 29, 2008 at 8:05 PM, Glenn Linderman [EMAIL PROTECTED] wrote:
On approximately 10/29/2008 3:45 PM, came the following characters from the
keyboard of Patrick Stinson:
If
Speaking of the big picture, is this how it normally works when
someone says Here's some code and a problem and I'm willing to pay
for a solution? I've never really walked that path with a project of
this complexity (I guess it's the backwards-compatibility that makes
it confusing), but is this
On Oct 30, 8:23 pm, Patrick Stinson [EMAIL PROTECTED]
wrote:
Speaking of the big picture, is this how it normally works when
someone says Here's some code and a problem and I'm willing to pay
for a solution? I've never really walked that path with a project of
this complexity (I guess it's the
On Oct 31, 2:05 am, Andy O'Meara [EMAIL PROTECTED] wrote:
I don't follow you there. If you're referring to multiprocessing, our
concerns are:
- Maturity (am I willing to tell my partners and employees that I'm
betting our future on a brand-new module that imposes significant
restrictions as
Close, I work currently for EastWest :)
Well, I actually like almost everything else about CPython,
considering my audio work the only major problem I've had is with the
GIL. I like the purist community, and I like the code, since
integrating it on both platforms has been relatively clean, and
Wow, man. Excellent post. You want a job?
The gui could use PyA threads for sure, and the audio thread could use
PyC threads. It would not be a problem to limit the audio thread to
only reentrant libraries.
This kind of thought is what I had in mind about finding a compromise,
especially in the
On Fri, Oct 24, 2008 at 12:51 PM, Andy O'Meara [EMAIL PROTECTED] wrote:
Another great post, Glenn!! Very well laid-out and posed!! Thanks for
taking the time to lay all that out.
Questions for Andy: is the type of work you want to do in independent
threads mostly pure Python? Or with
On 28 Okt, 21:03, Rhamphoryncus [EMAIL PROTECTED] wrote:
* get a short-term bodge that works, like hacking the 3rd party
library to use your shared-memory allocator. Should be far less work
than hacking all of CPython.
Did anyone come up with a reason why shared memory couldn't be used
for
On Oct 29, 7:20 am, Paul Boddie [EMAIL PROTECTED] wrote:
On 28 Okt, 21:03, Rhamphoryncus [EMAIL PROTECTED] wrote:
* get a short-term bodge that works, like hacking the 3rd party
library to use your shared-memory allocator. Should be far less work
than hacking all of CPython.
Did anyone
If you are dealing with lots of data like in video or sound editing,
you would just keep the data in shared memory and send the reference
over IPC to the worker process. Otherwise, if you marshal and send you
are looking at a temporary doubling of the memory footprint of your
app because the data
On Oct 26, 6:57 pm, Andy O'Meara [EMAIL PROTECTED] wrote:
Grrr... I posted a ton of lengthy replies to you and other recent
posts here using Google and none of them made it, argh. Poof. There's
nothing that fires more up more than lost work, so I'll have to
revert short and simple answers for
Glenn Linderman wrote:
so a 3rd party library might be called to decompress the stream into a
set of independently allocated chunks, each containing one frame (each
possibly consisting of several allocations of memory for associated
metadata) that is independent of other frames
We use a
Philip Semanchuk wrote:
On Oct 25, 2008, at 7:53 AM, Michael Sparks wrote:
Glenn Linderman wrote:
In the module multiprocessing environment could you not use shared
memory, then, for the large shared data items?
If the poshmodule had a bit of TLC, it would be extremely useful for
this,...
On Oct 26, 10:11 pm, James Mills [EMAIL PROTECTED]
wrote:
On Mon, Oct 27, 2008 at 12:03 PM, Andy O'Meara [EMAIL PROTECTED] wrote:
I think we miscommunicated there--I'm actually agreeing with you. I
was trying to make the same point you were: that intricate and/or
large structures are meant
On Oct 27, 4:05 am, Martin v. Löwis [EMAIL PROTECTED] wrote:
Andy O'Meara wrote:
Well, when you're talking about large, intricate data structures
(which include opaque OS object refs that use process-associated
allocators), even a shared memory region between the child process and
the
Glenn Linderman wrote:
So your 50% number is just a scare tactic, it would seem, based on wild
guesses. Was there really any benefit to the comment?
All I was really trying to say is that it would be a
mistake to assume that the overhead will be negligible,
as that would be just as much a
On Oct 25, 9:46 am, M.-A. Lemburg [EMAIL PROTECTED] wrote:
These discussion pop up every year or so and I think that most of them
are not really all that necessary, since the GIL isn't all that bad.
Thing is, if the topic keeps coming up, then that may be an indicator
that change is truly
On Oct 27, 10:55 pm, Glenn Linderman [EMAIL PROTECTED] wrote:
And I think we still are miscommunicating! Or maybe communicating anyway!
So when you said object, I actually don't know whether you meant
Python object or something else. I assumed Python object, which may not
have been
On Oct 28, 9:30 am, Andy O'Meara [EMAIL PROTECTED] wrote:
On Oct 25, 9:46 am, M.-A. Lemburg [EMAIL PROTECTED] wrote:
These discussion pop up every year or so and I think that most of them
are not really all that necessary, since the GIL isn't all that bad.
Thing is, if the topic keeps
Because then we're back into the GIL not permitting threads efficient
core use on CPU bound scripts running on other threads (when they
otherwise could).
Why do you think so? For C code that is carefully written, the GIL
allows *very well* to write CPU bound scripts running on other threads.
Andy O'Meara wrote:
On Oct 24, 9:52 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
A c-level module, on the other hand, can sidestep/release
the GIL at will, and go on it's merry way and process away.
...Unless part of the C module execution involves the need do CPU-
bound work on another
As far as I can tell, it seems
CPython's current state can't CPU bound parallelization in the same
address space.
That's not true.
Um... So let's say you have a opaque object ref from the OS that
represents hundreds of megs of data (e.g. memory-resident video). How
do you get that back
Andy O'Meara Wrote:
Um... So let's say you have a opaque object ref from the OS that
represents hundreds of megs of data (e.g. memory-resident video). How
do you get that back to the parent process without serialization and
IPC? What should really happen is just use the same address space so
Grrr... I posted a ton of lengthy replies to you and other recent
posts here using Google and none of them made it, argh. Poof. There's
nothing that fires more up more than lost work, so I'll have to
revert short and simple answers for the time being. Argh, damn.
On Oct 25, 1:26 am, greg
On Oct 24, 9:52 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
A c-level module, on the other hand, can sidestep/release
the GIL at will, and go on it's merry way and process away.
...Unless part of the C module execution involves the need do CPU-
bound work on another thread through a
And in the case of hundreds of megs of data
... and I would be surprised at someone that would embed hundreds of
megs of data into an object such that it had to be serialized... seems
like the proper design is to point at the data, or a subset of it, in a
big buffer. Then data transfers
On Mon, Oct 27, 2008 at 12:03 PM, Andy O'Meara [EMAIL PROTECTED] wrote:
I think we miscommunicated there--I'm actually agreeing with you. I
was trying to make the same point you were: that intricate and/or
large structures are meant to be passed around by a top-level pointer,
not using and
Andy O'Meara wrote:
- each worker thread makes its own interpreter, pops scripts off a
work queue, and manages exporting (and then importing) result data to
other parts of the app.
I hope you realize that starting up one of these interpreters
is going to be fairly expensive. It will have to
Glenn Linderman wrote:
If Py_None corresponds to None in Python syntax ... then
it is a fixed constant and could be left global, probably.
No, it couldn't, because it's a reference-counted object
like any other Python object, and therefore needs to be
protected against simultaneous refcount
Andy O'Meara wrote:
In our case, we're doing image and video
manipulation--stuff not good to be messaging from address space to
address space.
Have you considered using shared memory?
Using mmap or equivalent, you can arrange for a block of
memory to be shared between processes. Then you can
Rhamphoryncus wrote:
A list
is not shareable, so it can only be used within the monitor it's
created within, but the list type object is shareable.
Type objects contain dicts, which allow arbitrary values
to be stored in them. What happens if one thread puts
a private object in there? It
If Py_None corresponds to None in Python syntax (sorry I'm not familiar
with Python internals yet; glad you are commenting, since you are), then
it is a fixed constant and could be left global, probably.
If None remains global, then type(None) also remains global, and
type(None),__bases__[0].
Hi Andy,
Andy wrote:
However, we require true thread/interpreter
independence so python 2 has been frustrating at time, to say the
least. Please don't start with but really, python supports multiple
interpreters because I've been there many many times with people.
And, yes, I'm aware of
Andy O'Meara wrote:
Yeah, that's the idea--let the highest levels run and coordinate the
show.
Yes, this works really well in python and it's lots of fun. We've found so
far you need at minimum the following parts to a co-ordination little
language:
Pipeline
Graphline
Carousel
Glenn Linderman wrote:
In the module multiprocessing environment could you not use shared
memory, then, for the large shared data items?
If the poshmodule had a bit of TLC, it would be extremely useful for this,
since it does (surprisingly) still work with python 2.5, but does need a
bit of
Andy O'Meara wrote:
basically, it seems that we're talking about the
embarrassingly parallel scenario raised in that paper
We build applications in Kamaelia and then discover afterwards that they're
embarrassingly parallel and just work. (we have an introspector that can
look inside running
Jesse Noller wrote:
http://www.kamaelia.org/Home
Thanks for the mention :)
I don't think it's a good fit for the original poster's question, but a
solution to the original poster's question would be generally useful IMO,
_especially_ on python implementations without a GIL (where threads are
These discussion pop up every year or so and I think that most of them
are not really all that necessary, since the GIL isn't all that bad.
Some pointers into the past:
* http://effbot.org/pyfaq/can-t-we-get-rid-of-the-global-interpreter-lock.htm
Fredrik on the GIL
*
Glenn Linderman wrote:
On approximately 10/24/2008 8:39 PM, came the following characters from
the keyboard of Terry Reedy:
Glenn Linderman wrote:
For example, Python presently has a rather stupid algorithm for
string concatenation.
Yes, CPython2.x, x=5 did.
Python the language has syntax
On Oct 25, 2008, at 7:53 AM, Michael Sparks wrote:
Glenn Linderman wrote:
In the module multiprocessing environment could you not use shared
memory, then, for the large shared data items?
If the poshmodule had a bit of TLC, it would be extremely useful for
this,
since it does
There are a number of problems with that approach. The biggest one is
that it is theoretical.
Not theoretical. Used successfully in Perl.
Perhaps it is indeed what Perl does, I know nothing about that.
However, it *is* theoretical for Python. Please trust me that
there are many many many
On Oct 24, 9:52 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
A c-level module, on the other hand, can sidestep/release
the GIL at will, and go on it's merry way and process away.
...Unless part of the C module execution involves the need do CPU-
bound work on another thread through a
On Oct 24, 9:40 pm, Martin v. Löwis [EMAIL PROTECTED] wrote:
It seems to me that the very simplest move would be to remove global
static data so the app could provide all thread-related data, which
Andy suggests through references to the QuickTime API. This would
suggest compiling python
On Oct 24, 10:24 pm, Glenn Linderman [EMAIL PROTECTED] wrote:
And in the case of hundreds of megs of data
... and I would be surprised at someone that would embed hundreds of
megs of data into an object such that it had to be serialized... seems
like the proper design is to point at the
Andy O'Meara wrote:
I would definitely agree if there was a context (i.e. environment)
object passed around then perhaps we'd have the best of all worlds.
Moreover, I think this is probably the *only* way that
totally independent interpreters could be realized.
Converting the whole C
On Oct 25, 12:29 am, greg [EMAIL PROTECTED] wrote:
Rhamphoryncus wrote:
A list
is not shareable, so it can only be used within the monitor it's
created within, but the list type object is shareable.
Type objects contain dicts, which allow arbitrary values
to be stored in them. What
Glenn Linderman wrote:
On approximately 10/25/2008 12:01 AM, came the following characters from
the keyboard of Martin v. Löwis:
If None remains global, then type(None) also remains global, and
type(None),__bases__[0]. Then type(None).__bases__[0].__subclasses__()
will yield interesting
Andy wrote:
1) Independent interpreters (this is the easier one--and solved, in
principle anyway, by PEP 3121, by Martin v. Löwis
Something like that is necessary for independent interpreters,
but not sufficient. There are also all the built-in constants
and type objects to consider. Most of
You seem confused. PEP 3121 is for isolated interpreters (ie emulated
processes), not threading.
Just a small remark: this wasn't the primary objective of the PEP.
The primary objective was to support module cleanup in a reliable
manner, to allow eventually to get modules garbage-collected
Instead of appdomains (one interpreter per thread), or free
threading, you could use multiple processes. Take a look at the new
multiprocessing module in Python 2.6. It has roughly the same
interface as Python's threading and queue modules, but uses processes
instead of threads. Processes are
On Oct 24, 9:35 am, sturlamolden [EMAIL PROTECTED] wrote:
Instead of appdomains (one interpreter per thread), or free
threading, you could use multiple processes. Take a look at the new
multiprocessing module in Python 2.6.
That's mentioned earlier in the thread.
There is a fundamental
Terry Reedy wrote:
Everything in DLLs is compiled C extensions. I see about 15 for Windows
3.0.
Ah, weren't that wonderful times back in the days of Win3.0, when DLL-hell was
inhabited by only 15 libraries? *sigh*
... although ... wait, didn't Win3.0 have more than that already? Maybe you
On Oct 24, 3:58 pm, Andy O'Meara [EMAIL PROTECTED] wrote:
This is discussed earlier in the thread--they're unfortunately all
out.
It occurs to me that tcl is doing what you want. Have you ever thought
of not using Python?
That aside, the fundamental problem is what I perceive a fundamental
On Oct 24, 2:12 am, greg [EMAIL PROTECTED] wrote:
Andy wrote:
1) Independent interpreters (this is the easier one--and solved, in
principle anyway, by PEP 3121, by Martin v. Löwis
Something like that is necessary for independent interpreters,
but not sufficient. There are also all the
That aside, the fundamental problem is what I perceive a fundamental
design flaw in Python's C API. In Java JNI, each function takes a
JNIEnv* pointer as their first argument. There is nothing the
prevents you from embedding several JVMs in a process. Python can
create embedded
I'm not finished reading the whole thread yet, but I've got some
things below to respond to this post with.
On Thu, Oct 23, 2008 at 9:30 AM, Glenn Linderman [EMAIL PROTECTED] wrote:
On approximately 10/23/2008 12:24 AM, came the following characters from the
keyboard of Christian Heimes:
Andy
Glenn, great post and points!
Andy seems to want an implementation of independent Python processes
implemented as threads within a single address space, that can be
coordinated by an outer application. This actually corresponds to the
model promulgated in the paper as being most likely to
We are in the same position as Andy here.
I think that something that would help people like us produce
something in code form is a collection of information outlining the
problem and suggested solutions, appropriate parts of the CPython's
current threading API, and pros and cons of the many
As a side note to the performance question, we are executing python
code in an audio thread that is used in all of the top-end music
production environments. We have found the language to perform
extremely well when executed at control-rate frequency, meaning we
aren't doing DSP computations, just
Stefan Behnel wrote:
Terry Reedy wrote:
Everything in DLLs is compiled C extensions. I see about 15 for Windows
3.0.
Ah, weren't that wonderful times back in the days of Win3.0, when DLL-hell was
inhabited by only 15 libraries? *sigh*
... although ... wait, didn't Win3.0 have more than that
On Fri, Oct 24, 2008 at 10:40 AM, Andy O'Meara [EMAIL PROTECTED] wrote:
2) Barriers to free threading. As Jesse describes, this is simply
just the GIL being in place, but of course it's there for a reason.
It's there because (1) doesn't hold and there was never any specs/
guidance put
On Fri, Oct 24, 2008 at 12:30 PM, Jesse Noller [EMAIL PROTECTED] wrote:
On Fri, Oct 24, 2008 at 10:40 AM, Andy O'Meara [EMAIL PROTECTED] wrote:
2) Barriers to free threading. As Jesse describes, this is simply
just the GIL being in place, but of course it's there for a reason.
It's there
The Global Interpreter Lock is fundamentally designed to make the
interpreter easier to maintain and safer: Developers do not need to
worry about other code stepping on their namespace. This makes things
thread-safe, inasmuch as having multiple PThreads within the same
interpreter space
On Fri, Oct 24, 2008 at 3:17 PM, Andy O'Meara [EMAIL PROTECTED] wrote:
I'm a lousy writer sometimes, but I feel bad if you took the time to
describe threads vs processes. The only reason I raised IPC with my
messaging isn't very attractive comment was to respond to Glenn
Linderman's points
On Oct 24, 1:02 pm, Glenn Linderman [EMAIL PROTECTED] wrote:
On approximately 10/24/2008 8:42 AM, came the following characters from
the keyboard of Andy O'Meara:
Glenn, great post and points!
Thanks. I need to admit here that while I've got a fair bit of
professional programming
Another great post, Glenn!! Very well laid-out and posed!! Thanks for
taking the time to lay all that out.
Questions for Andy: is the type of work you want to do in independent
threads mostly pure Python? Or with libraries that you can control to
some extent? Are those libraries reentrant?
On approximately 10/24/2008 1:09 PM, came the following characters from
the keyboard of Rhamphoryncus:
On Oct 24, 1:02 pm, Glenn Linderman [EMAIL PROTECTED] wrote:
On approximately 10/24/2008 8:42 AM, came the following characters from
the keyboard of Andy O'Meara:
Glenn, great post
On Fri, Oct 24, 2008 at 4:51 PM, Andy O'Meara [EMAIL PROTECTED] wrote:
In the module multiprocessing environment could you not use shared
memory, then, for the large shared data items?
As I understand things, the multiprocessing puts stuff in a child
process (i.e. a separate address space),
1 - 100 of 126 matches
Mail list logo
