Josiah Carlson wrote:
> I do, however, doubt that free threading approaches will be the future
> for concurrent programming in CPython.
Hear, hear! IMO, it's the combination of the GIL with a compiler which never
decides to change the code execution order under the covers that makes
threading *n
Bruce Eckel <[EMAIL PROTECTED]> wrote:
>
> > I can (but won't) point out examples for days of bad decisions made for
> > the sake of speed, or policy that has been ignored for the sake of speed
> > (some of these overlap and some don't).
>
> As long as you've entered premature-optimization land,
> I can (but won't) point out examples for days of bad decisions made for
> the sake of speed, or policy that has been ignored for the sake of speed
> (some of these overlap and some don't).
As long as you've entered premature-optimization land, how about
decisions made because it's *assumed* that
On 10/8/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Your malicious user is my inventive colleague. Here's one: performing
> zero-copy inter-thread IPC by modifying shared immutables. Attempting to
> enforce a policy of "don't do that, it's not supported" is not going to
> be effective, especia
Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 10/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > I need to stress that *only* the new, immutable and "thread-safe
> > > mark-and-sweep" types would be affected by these changes. Everything
> > > else woul
On 10/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Adam Olsen <[EMAIL PROTECTED]> wrote:
> > I need to stress that *only* the new, immutable and "thread-safe
> > mark-and-sweep" types would be affected by these changes. Everything
> > else would continue to exist as it did before, and the b
On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:17 PM 10/7/2005 -0600, Adam Olsen wrote:
> >On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > Note that implementing a root-based GC for Python is non-trivial, since
> > > extension modules can store pointers to PyObjects anywh
At 07:17 PM 10/7/2005 -0600, Adam Olsen wrote:
>On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
> > >Turns out it's quite easy and it doesn't harm performance of existing
> > >code or require modification (but a recompile is necessary). The
Adam Olsen <[EMAIL PROTECTED]> wrote:
> I need to stress that *only* the new, immutable and "thread-safe
> mark-and-sweep" types would be affected by these changes. Everything
> else would continue to exist as it did before, and the benchmark
> exists to show they can coexist without killing perf
On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
> >Okay, basic principal first. You start with a sandboxed thread that
> >has access to nothing. No modules, no builtins, *nothing*. This
> >means it can run without the GIL but it can't do any
Phillip J. Eby wrote:
> Oh, and don't forget - newstyle classes keep weak references to all their
> subclasses, which means for example that every time you subclass 'dict',
> you're modifying the "immutable" 'dict' class. So, unless you recreate all
> the classes in each sandbox, you're back to
At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
>Okay, basic principal first. You start with a sandboxed thread that
>has access to nothing. No modules, no builtins, *nothing*. This
>means it can run without the GIL but it can't do any work.
It sure can't. You need at least the threadstate and
Okay, basic principal first. You start with a sandboxed thread that
has access to nothing. No modules, no builtins, *nothing*. This
means it can run without the GIL but it can't do any work. To make it
do something useful we need to give it two things: first, immutable
types that can be safely
13 matches
Mail list logo
