Aahz, 01.03.2011 03:02:
Carl Banks wrote:
The real reason they never replaced the GIL is that fine-grained
locking is expensive with reference counting. The only way the cost
of finer-grained locking would be acceptable, then, is if they got rid
of the reference counting altogether, and that w
In article ,
Carl Banks wrote:
>
>The real reason they never replaced the GIL is that fine-grained
>locking is expensive with reference counting. The only way the cost
>of finer-grained locking would be acceptable, then, is if they got rid
>of the reference counting altogether, and that was cons
On Feb 8, 7:12 pm, Paul Rubin wrote:
> But the refcount scheme is just an implementation hack
> that gets rationalized way too much. I hope PyPy abandons it.
Done. :)
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
sturlamolden writes:
> comes with a cost. The interpreter will sometimes pause to collect
> garbage. The memory use will be larger as well, as garbage remain
> uncollected for a while and is not immediately reclaimed. Many rely on
> CPython because the interpreter does not pause and a Python proce
On 8 Feb, 10:39, Vishal wrote:
> Is it possible that the Python process, creates copies of the
> interpreter for each thread that is launched, and some how the thread
> is bound to its own interpreter ?
In .NET lingo this is called an 'AppDomain'. This is also how tcl
works -- one interpreter p
On Feb 8, 11:49 am, John Nagle wrote:
> The real reason for the GIL, though, is to support dynamic
> code modification in multi-thread progrems. It's the ability
> to replace a function while it's being executed in another thread
> that's hard to do without a global lock. If it were just a d
On 2/8/2011 1:39 AM, Vishal wrote:
Hello,
This might sound crazy..and dont know if its even possible, but...
Is it possible that the Python process, creates copies of the
interpreter for each thread that is launched, and some how the thread
is bound to its own interpreter ?
This will increase
On Tue, 2011-02-08 at 11:52 -0500, Roy Smith wrote:
> In article ,
> Robert Kern wrote:
> > Unlike a UNIX fork, CreateProcess() does not have the same copy-on-write
> > semantics for initializing the memory of the new process. If you want to
> > pass
> > data to the children, the data must be
Roy Smith, 08.02.2011 17:52:
Robert Kern wrote:
Unlike a UNIX fork, CreateProcess() does not have the same copy-on-write
semantics for initializing the memory of the new process. If you want to pass
data to the children, the data must be pickled and sent across the process
boundary. He's not sa
In article ,
Robert Kern wrote:
> Unlike a UNIX fork, CreateProcess() does not have the same copy-on-write
> semantics for initializing the memory of the new process. If you want to pass
> data to the children, the data must be pickled and sent across the process
> boundary. He's not saying t
On 2/8/11 10:11 AM, Brian Curtin wrote:
On Tue, Feb 8, 2011 at 06:34, Vishal mailto:vsapr...@gmail.com>> wrote:
Also, multiprocessing has issues on Windows (most probably because of
the way CreateProcess() functions...)
Such as?
Unlike a UNIX fork, CreateProcess() does not have the sa
On Tue, Feb 8, 2011 at 06:34, Vishal wrote:
> Also, multiprocessing has issues on Windows (most probably because of
> the way CreateProcess() functions...)
Such as?
--
http://mail.python.org/mailman/listinfo/python-list
On Feb 8, 7:34 am, Vishal wrote:
> On Feb 8, 3:05 pm, Adam Tauno Williams wrote:
>
> > On Tue, 2011-02-08 at 01:39 -0800, Vishal wrote:
> > > Is it possible that the Python process, creates copies of the
> > > interpreter for each thread that is launched, and some how the thread
> > > is bound to
On Feb 8, 3:05 pm, Adam Tauno Williams wrote:
> On Tue, 2011-02-08 at 01:39 -0800, Vishal wrote:
> > Is it possible that the Python process, creates copies of the
> > interpreter for each thread that is launched, and some how the thread
> > is bound to its own interpreter ?
> > and it "may" also a
On Tue, 2011-02-08 at 01:39 -0800, Vishal wrote:
> Is it possible that the Python process, creates copies of the
> interpreter for each thread that is launched, and some how the thread
> is bound to its own interpreter ?
> and it "may" also allow the two threads to run in parallel, assuming
> the
Hello,
This might sound crazy..and dont know if its even possible, but...
Is it possible that the Python process, creates copies of the
interpreter for each thread that is launched, and some how the thread
is bound to its own interpreter ?
This will increase the python process size...for sure, h
16 matches
Mail list logo
