On Mon, May 27, 2013 at 4:07 PM, Ian Kelly wrote:
> On Sun, May 26, 2013 at 10:36 PM, Peter Brooks
> wrote:
>> This makes complete sense - any atomic action should be atomic, so two
>> threads can't be doing it at the same time. They can be doing anything
>> else though.
>>
>> If two threads crea
On Mon, May 27, 2013 at 12:19 AM, Ian Kelly wrote:
> 7) Since the program being tested does basically nothing except start
> and exit threads, the extra 40% probably represents the overhead of
> all that starting and stopping, which would be done outside the GIL.
To test this, I tried running the
On Sun, May 26, 2013 at 4:16 PM, Chris Angelico wrote:
> On Mon, May 27, 2013 at 5:35 AM, Ian Kelly wrote:
>> I'm pretty sure that CPython uses the GIL regardless of platform. And
>> yes you can have multiple OS-level threads, but because of the GIL
>> only one will actually be running at a time
On Sun, May 26, 2013 at 10:36 PM, Peter Brooks
wrote:
> This makes complete sense - any atomic action should be atomic, so two
> threads can't be doing it at the same time. They can be doing anything
> else though.
>
> If two threads create a new object at the same time, for example,
> there's pot
On May 27, 12:16 am, Chris Angelico wrote:
> On Mon, May 27, 2013 at 5:35 AM, Ian Kelly wrote:
> > I'm pretty sure that CPython uses the GIL regardless of platform. And
> > yes you can have multiple OS-level threads, but because of the GIL
> > only one will actually be running at a time. Other
On Mon, May 27, 2013 at 5:35 AM, Ian Kelly wrote:
> I'm pretty sure that CPython uses the GIL regardless of platform. And
> yes you can have multiple OS-level threads, but because of the GIL
> only one will actually be running at a time. Other possibilities
> include:
6) It's spinning in a func
On Sun, May 26, 2013 at 12:13 PM, Peter Brooks
wrote:
> No, on a multi-core machine it's normal. The machine shows python
> running multiple threads - and the number of threads change as the
> program runs. Perhaps the OS/X implementation of python does allow
> concurrency when others don't. It ce
On 26 May, 20:22, Carlos Nepomuceno
wrote:
>
>
> > Date: Sun, 26 May 2013 11:13:12 -0700
> > Subject: Re: Solving the problem of mutual recursion
> > From: peter.h.m.bro...@gmail.com
> > To: python-l...@python.org
> [...]
> Date: Sun, 26 May 2013 11:13:12 -0700
> Subject: Re: Solving the problem of mutual recursion
> From: peter.h.m.bro...@gmail.com
> To: python-list@python.org
[...]
>> How can you get 140% of CPU? IS that a typo??
>>
> No, o
On 26 May, 20:09, Carlos Nepomuceno
wrote:
>
>
>
>
>
>
>
>
>
>
> > Date: Sun, 26 May 2013 10:21:05 -0700
> > Subject: Re: Solving the problem of mutual recursion
> > From: peter.h.m.bro...@gmail.com
> &g
> Date: Sun, 26 May 2013 10:21:05 -0700
> Subject: Re: Solving the problem of mutual recursion
> From: peter.h.m.bro...@gmail.com
> To: python-list@python.org
>
> On May 26, 5:09 pm, Jussi Piitulainen
> wrote:
>>
>> A l
On May 26, 5:09 pm, Jussi Piitulainen
wrote:
>
> A light-weighter way is to have each task end by assigning the next
> task and returning, instead of calling the next task directly. When a
> task returns, a driver loop will call the assigned task, which again
> does a bounded amount of work, assig
In article ,
Jussi Piitulainen wrote:
> A light-weighter way is to have each task end by assigning the next
> task and returning, instead of calling the next task directly. When a
> task returns, a driver loop will call the assigned task, which again
> does a bounded amount of work, assigns the
Peter Brooks writes:
> I'm not sure if this'll interest anybody, but I expect that I'm
> going to get some mutual recursion in my simulation, so I needed to
...
> returned, then this solution won't help you. Often, though, you're
> not interested in what's returned and would just like the routine
I'm not sure if this'll interest anybody, but I expect that I'm going
to get some mutual recursion in my simulation, so I needed to see how
python handled it. Unfortunately, it falls over once it detects a
certain level of recursion. This is reasonable as, otherwise, the
stack eventually over-fills
15 matches
Mail list logo