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

Groups > comp.lang.python > #46158

Re: Solving the problem of mutual recursion

Show all headers | View raw

On May 27, 12:16 am, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, May 27, 2013 at 5:35 AM, Ian Kelly <ian.g.ke...@gmail.com> 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 function that has released the GIL. Python
> threads can certainly execute concurrently; they just can't be
> manipulating Python objects. Most of the I/O functions will release
> the GIL before doing a potentially-blocking operation, and some
> CPU-heavy functions can do the same (I'm given to understand that
> numpy does this) - just depends on having a long job that involves no
> refcounted objects.
>
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.

This is an interesting subject.. There's nothing wrong with the tool
I'm using to report threads - 'Activity Monitor' is the standard
process monitor. It counts cores as 'CPUs', which seems perfectly
reasonable to me. As I said, other Unixes, such as HP-UX, do the same
thing.

I'm not quite sure of the best way to examine the exact behaviour.
Since the blocking works at the level of atomic operations, it's
difficult to detect - a call to an atomic operation may block all
other threads, but any snapshot of the number of active threads won't
be running at this time, so will only report when there are multiple
threads active.

Back to comp.lang.python | Previous | Next — Previous 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