<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 20, 2012 at 10:43 AM, Trent Nelson <span dir="ltr"><<a href="mailto:trent@snakebite.org" target="_blank">trent@snakebite.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">    This seems odd to me so I wanted to see what others think.  The unit<br>
    test Lib/unittest/test/test_runner.py:Test_TextRunner.test_warnings<br>
    will eventually hit subprocess.Popen._communicate.<br>
<br>
    The `mswindows` implementation of this method relies on threads to<br>
    buffer stdin/stdout.  That'll eventually result in PyOs_StdioReadline<br>
    being called without the GIL being held.  PyOs_StdioReadline calls<br>
    PyMem_MALLOC, PyMem_FREE and possibly PyMem_REALLOC.<br></blockquote><div><br></div><div style>Those threads are implemented in Python so how would the GIL ever not be held?</div><div style><br></div><div style>-gps</div>

<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    On a debug build, these macros are redirected to their _PyMem_Debug*<br>
    counterparts.  The call hierarchy for _PyMem_DebugMalloc looks like<br>
    this:<br>
<br>
        void *<br>
        _PyMem_DebugMalloc(size_t nbytes)<br>
        {<br>
            return _PyObject_DebugMallocApi(_PYMALLOC_MEM_ID, nbytes);<br>
        }<br>
<br>
        /* generic debug memory api, with an "id" to<br>
           identify the API in use */<br>
        void *<br>
        _PyObject_DebugMallocApi(char id, size_t nbytes)<br>
        {<br>
            uchar *p;           /* base address of malloc'ed block */<br>
            uchar *tail;        /* p + 2*SST + nbytes ==<br>
                                   pointer to tail pad bytes */<br>
            size_t total;       /* nbytes + 4*SST */<br>
<br>
            bumpserialno();<br>
------------^^^^^^^^^^^^^^^<br>
<br>
            total = nbytes + 4*SST;<br>
            if (total < nbytes)<br>
                /* overflow:  can't represent total as a size_t */<br>
                return NULL;<br>
<br>
            p = (uchar *)PyObject_Malloc(total);<br>
-------------------------^^^^^^^^^^^^^^^^^^^^^^^<br>
            if (p == NULL)<br>
                return NULL;<br>
<br>
            <snip><br>
<br>
    Both bumpserialno() and PyObject_Malloc affect global state.  The latter<br>
    also has a bunch of LOCK() and UNLOCK() statements, but these end up being<br>
    no-ops:<br>
<br>
        /*<br>
         * Python's threads are serialized,<br>
         * so object malloc locking is disabled.<br>
         */<br>
        #define SIMPLELOCK_DECL(lock) /* simple lock declaration */<br>
        #define SIMPLELOCK_INIT(lock) /* allocate (if needed) and ... */<br>
        #define SIMPLELOCK_FINI(lock) /* free/destroy an existing */<br>
        #define SIMPLELOCK_LOCK(lock) /* acquire released lock */<br>
        #define SIMPLELOCK_UNLOCK(lock) /* release acquired lock */<br>
        ...<br>
        /*<br>
         * This malloc lock<br>
         */<br>
        SIMPLELOCK_DECL(_malloc_lock)<br>
        #define LOCK()          SIMPLELOCK_LOCK(_malloc_lock)<br>
        #define UNLOCK()        SIMPLELOCK_UNLOCK(_malloc_lock)<br>
        #define LOCK_INIT()     SIMPLELOCK_INIT(_malloc_lock)<br>
        #define LOCK_FINI()     SIMPLELOCK_FINI(_malloc_lock)<br>
<br>
    The PyObject_Malloc() one concerns me the most, as it affects huge<br>
    amounts of global state.  Also, I just noticed PyOs_StdioReadline()<br>
    can call PyErr_SetString, which will result in a bunch of other<br>
    calls that should only be made whilst the GIL is held.<br>
<br>
    So, like I said, this seems like a bit of a head scratcher.  Legit<br>
    issue or am I missing something?<br>
<br>
        Trent.<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/greg%40krypto.org" target="_blank">http://mail.python.org/mailman/options/python-dev/greg%40krypto.org</a><br>
</blockquote></div><br></div></div>