Re: [pypy-dev] [pypy-svn] r27660 - in pypy/branch/njriley-trans/pypy: rpython/lltypesystem translator/c
njriley@codespeak.net writes:
Would this change make sense on the trunk too? Cheers, mwh -- Hmmm... its Sunday afternoon: I could do my work, or I could do a Fourier analysis of my computer's fan noise. -- Amit Muthu, ucam.chat (from Owen Dunn's summary of the year)
On Wed, May 24, 2006 at 10:21:08PM +0100, Michael Hudson wrote:
Assuming the GIL model, I don't see anywhere that the exception state gets swapped on a thread switch now; so, if this is the case, then yes, they'd make sense. With actual concurrent execution as I'm doing, that wouldn't help, of course. My changes would be fine if we could expect __thread (or some equivalent compiler-managed TLS) to be available everywhere, but PyPy doesn't make that assumption (see Samuele's work, e.g. pypy.translator.tool.cbuild.check_under_under_thread). The work I did for the old, pre-exceptiontransform model used pthread thread-specific variables, which would be possible as an alternative, but it'd take some work to automatically generate, and it'd impose considerably higher overhead on exception accesses. -- Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
On Wed, May 24, 2006 at 10:21:08PM +0100, Michael Hudson wrote:
Assuming the GIL model, I don't see anywhere that the exception state gets swapped on a thread switch now; so, if this is the case, then yes, they'd make sense. With actual concurrent execution as I'm doing, that wouldn't help, of course. My changes would be fine if we could expect __thread (or some equivalent compiler-managed TLS) to be available everywhere, but PyPy doesn't make that assumption (see Samuele's work, e.g. pypy.translator.tool.cbuild.check_under_under_thread). The work I did for the old, pre-exceptiontransform model used pthread thread-specific variables, which would be possible as an alternative, but it'd take some work to automatically generate, and it'd impose considerably higher overhead on exception accesses. -- Nicholas Riley <njriley@uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley>
participants (2)
-
Michael Hudson -
Nicholas Riley