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
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 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 softwar
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
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:
>
> > - M
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
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
> 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 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
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
> > allocato
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
> > 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
6 am, greg <[EMAIL PROTECTED]> wrote:
> 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
>
> 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 cou
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
> 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
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
>
> 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
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
> 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 subinte
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
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 fundamen
27 matches
Mail list logo
