Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #46178

Re: Solving the problem of mutual recursion

References (4 earlier) <074eac8a-1bc4-4fe0-afa9-1f52405f81d5@k3g2000vbn.googlegroups.com> <CALwzidkUtWZvVvdKhU7usYw2e926z4XT_hvHTKOQbDGmmLMCQg@mail.gmail.com> <mailman.2209.1369606596.3114.python-list@python.org> <9890fd93-fd9b-4865-a01e-4cd1d558d5fc@w15g2000vbn.googlegroups.com> <CALwzidnz1Fnrg1W3AtF+WLk7hX88N=4A4_NK4dKV1UfWZhYMig@mail.gmail.com>
Date 2013-05-27 17:37 +1000
Subject Re: Solving the problem of mutual recursion
From Chris Angelico <rosuav@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.2239.1369640244.3114.python-list@python.org> (permalink)

Show all headers | View raw


On Mon, May 27, 2013 at 4:07 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Sun, May 26, 2013 at 10:36 PM, Peter Brooks
> <peter.h.m.brooks@gmail.com> 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 potentially the problem that they'll get the same space, so
>> the object will be owned by both. To prevent this, the new object call
>> should be run in only one thread.
>>
>> If you have two objects running their methods on their own local
>> variables, then there's no potential for conflict, so there's no need
>> for them to be blocked.
>
> That's not the way it works. [snip details]

You're actually both saying the same thing, except that Peter went for
finer granularity than Ian and CPython did. CPython figures that, with
a refcounted heap, there's not a lot of point having separate mutex
locks for different operations. Other language interpreters have made
other choices. But Peter's analysis is still correct; it's just that
guarding it is simplified down to a binary state: either you have the
GIL, or you don't.

ChrisA

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 04:49 -0700
  Re: Solving the problem of mutual recursion Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2013-05-26 18:09 +0300
    Re: Solving the problem of mutual recursion Roy Smith <roy@panix.com> - 2013-05-26 11:23 -0400
    Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 10:21 -0700
      RE: Solving the problem of mutual recursion Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-26 21:09 +0300
        Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 11:13 -0700
          RE: Solving the problem of mutual recursion Carlos Nepomuceno <carlosnepomuceno@outlook.com> - 2013-05-26 21:22 +0300
            Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 12:05 -0700
          Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-26 13:35 -0600
          Re: Solving the problem of mutual recursion Chris Angelico <rosuav@gmail.com> - 2013-05-27 08:16 +1000
            Re: Solving the problem of mutual recursion Peter Brooks <peter.h.m.brooks@gmail.com> - 2013-05-26 21:36 -0700
              Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-27 00:07 -0600
              Re: Solving the problem of mutual recursion Chris Angelico <rosuav@gmail.com> - 2013-05-27 17:37 +1000
          Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-27 00:19 -0600
          Re: Solving the problem of mutual recursion Ian Kelly <ian.g.kelly@gmail.com> - 2013-05-27 01:04 -0600

csiph-web