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


Groups > comp.lang.python > #70699

Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution

X-Received by 10.43.75.198 with SMTP id zb6mr12403827icb.22.1398725427950; Mon, 28 Apr 2014 15:50:27 -0700 (PDT)
X-Received by 10.182.79.66 with SMTP id h2mr61320obx.21.1398725427854; Mon, 28 Apr 2014 15:50:27 -0700 (PDT)
Path csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!uq10no102428igb.0!news-out.google.com!en3ni366igc.0!nntp.google.com!uq10no102419igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups comp.lang.python
Date Mon, 28 Apr 2014 15:50:27 -0700 (PDT)
In-Reply-To <mailman.9531.1398609228.18130.python-list@python.org>
Complaints-To groups-abuse@google.com
Injection-Info glegroupsg2000goo.googlegroups.com; posting-host=2001:4900:1044:0:5403:9cb:391e:a2b2; posting-account=UQCN0woAAACDqrqYc9BqOlS7_Ifh1sg7
NNTP-Posting-Host 2001:4900:1044:0:5403:9cb:391e:a2b2
References <a087ae04-a87c-4e77-a7dd-2d883d30a6f0@googlegroups.com> <mailman.9495.1398434710.18130.python-list@python.org> <675725e3-38d2-4d81-bf64-f6d903d4a684@googlegroups.com> <mailman.9531.1398609228.18130.python-list@python.org>
User-Agent G2/1.0
MIME-Version 1.0
Message-ID <b442b64d-b79c-4c0e-9df4-e3c3ae47ee9e@googlegroups.com> (permalink)
Subject Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution
From Matthew Pounsett <matt.pounsett@gmail.com>
Injection-Date Mon, 28 Apr 2014 22:50:27 +0000
Content-Type text/plain; charset=ISO-8859-1
Content-Transfer-Encoding quoted-printable
Xref csiph.com comp.lang.python:70699

Show key headers only | View raw


On Sunday, 27 April 2014 10:33:38 UTC-4, Chris Angelico  wrote:
> In most contexts, "thread unsafe" simply means that you can't use the 
> same facilities simultaneously from two threads (eg a lot of database
> connection libraries are thread unsafe with regard to a single
> connection, as they'll simply write to a pipe or socket and then read
> a response from it). But processes and threads are, on many systems,
> linked. Just the act of spinning off a new thread and then forking can
> potentially cause problems. Those are the exact sorts of issues that
> you'll see when you switch OSes, as it's the underlying thread/process
> model that's significant. (Particularly of note is that Windows is
> *very* different from Unix-based systems, in that subprocess
> management is not done by forking. But not applicable here.)
> 

Thanks, I'll keep all that in mind.  I have to wonder how much of a problem it is here though, since I was able to demonstrate a functioning fork inside a new thread further up in the discussion.

I have a new development that I find interesting, and I'm wondering if you still think it's the same problem.

I have taken that threading object and turned it into a normal function definition.  It's still forking the external tool, but it's doing so in the main thread, and it is finished execution before any other threads are created.   And I'm still getting the same error.

Turns out it's not coming from the threading module, but from the subprocess module instead.  Specifically, like 709 of /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py
which is this:

        try:
            self._execute_child(args, executable, preexec_fn, close_fds,
                                cwd, env, universal_newlines,
                                startupinfo, creationflags, shell, to_close,
                                p2cread, p2cwrite,
                                c2pread, c2pwrite,
                                errread, errwrite)
        except Exception:

I get the "Warning: No stack to get attribute from" twice when that self._execute_child() call is made.  I've tried stepping into it to narrow it down further, but I'm getting weird behaviour from the debugger that I've never seen before once I do that.  It's making it hard to track down exactly where the error is occurring.

Interestingly, it's not actually raising an exception there.  The except block is not being run.

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


Thread

MacOS 10.9.2: threading error using python.org 2.7.6 distribution Matthew Pounsett <matt.pounsett@gmail.com> - 2014-04-25 06:43 -0700
  Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution Chris Angelico <rosuav@gmail.com> - 2014-04-26 00:05 +1000
    Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution Matthew Pounsett <matt.pounsett@gmail.com> - 2014-04-27 07:16 -0700
      Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution Chris Angelico <rosuav@gmail.com> - 2014-04-28 00:33 +1000
        Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution Matthew Pounsett <matt.pounsett@gmail.com> - 2014-04-28 15:50 -0700
          Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution Chris Angelico <rosuav@gmail.com> - 2014-04-29 09:00 +1000
  Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution Ned Deily <nad@acm.org> - 2014-04-25 11:58 -0700
    Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution Matthew Pounsett <matt.pounsett@gmail.com> - 2014-04-27 07:18 -0700

csiph-web