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: 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: <675725e3-38d2-4d81-bf64-f6d903d4a684@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: MacOS 10.9.2: threading error using python.org 2.7.6 distribution From: Matthew Pounsett 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 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=20 > 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.) >=20 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 insi= de 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 def= inition. It's still forking the external tool, but it's doing so in the ma= in thread, and it is finished execution before any other threads are create= d. And I'm still getting the same error. Turns out it's not coming from the threading module, but from the subproces= s module instead. Specifically, like 709 of /Library/Frameworks/Python.fra= mework/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._e= xecute_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 whe= re the error is occurring. Interestingly, it's not actually raising an exception there. The except bl= ock is not being run.