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 memcp
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.
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
talk
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 state
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
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
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 proce
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 sti
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 leve
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 im
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/...http://groups.google.com/group/comp.lang.python/msg/edae2840ab432344http://groups.google.com/gr
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 multip
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 sh
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
> process
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
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 thi
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 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 spe
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 python-to-j
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
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
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
> restri
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
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 p
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 y
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 sh
>> 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 multip
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 heavy
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 completel
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 bein
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
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 An
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
>> > otherwi
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 G
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 sh
> 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
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 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.
>
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
fo
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
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 w
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
req
> 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.
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 t
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 bee
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 trul
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 wil
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
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 structur
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
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 c
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 answ
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 wor
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 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 tran
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
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 <[EMA
"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 spac
>>> 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 y
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" resu
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.
> 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 w
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
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 compili
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
>> 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
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 (surprisingl
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
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
* http://mail.python.org/
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 t
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
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 T
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
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 awar
> 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]
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 become
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
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 ma
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 cr
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 API to u
Glenn Linderman wrote:
For example, Python presently has a rather stupid algorithm for string
concatenation.
Python the language has syntax and semantics. Python implementations
have algorithms that fulfill the defined semantics.
It allocates only the exactly necessary space for the
conca
> 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 without thread support so as to leave it up
> to the applicatio
>> 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 different python interpreter,
> right?
Wrong.
> (even if th
On Fri, Oct 24, 2008 at 5:38 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/24/2008 2:16 PM, came the following characters from the
> keyboard of Rhamphoryncus:
>>
>> On Oct 24, 3:02 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On approximately 10/23/2008 2:24 PM,
On Fri, Oct 24, 2008 at 4:48 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/24/2008 2:15 PM, came the following characters from the
> keyboard of Rhamphoryncus:
>>
>> On Oct 24, 2:59 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On approximately 10/24/2008 1:09 PM,
> Are you familiar with the API at all? Multiprocessing was designed to
> mimic threading in about every way possible, the only restriction on
> shared data is that it must be serializable, but event then you can
> override or customize the behavior.
>
> Also, inter process communication is done
On Oct 24, 3:02 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/23/2008 2:24 PM, came the following characters from the
> keyboard of Rhamphoryncus:
>>
>> On Oct 23, 11:30 am, Glenn Linderman <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On approximately 10/23/2008 12:24 AM, came the f
On Oct 24, 2:59 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> On approximately 10/24/2008 1:09 PM, came the following characters from
> the keyboard of Rhamphoryncus:
> > PyE: objects are reclassified as shareable or non-shareable, many
> > types are now only allowed to be shareable. A module a
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 addre
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
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 reentran
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
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 p
>
> 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 spa
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.
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/
>> > g
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
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
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 vario
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
1 - 100 of 126 matches
Mail list logo
