Charles R Harris wrote:
On Sat, Apr 26, 2008 at 11:21 AM, Travis E. Oliphant <oliphant@enthought.com <mailto:oliphant@enthought.com>> wrote:
Charles R Harris wrote: > Travis, > > Is this correct? > Yes. > NPY_LOOP_BEGIN_THREADS; > switch(loop->meth) { > case ONE_UFUNCLOOP: > /* > * Everything is contiguous, notswapped, aligned, > * and of the right type. -- Fastest. > * Or if not contiguous, then a single-stride > * increment moves through the entire array. > */ > /*fprintf(stderr, "ONE...%d\n", loop->size);*/ > loop->function((char **)loop->bufptr, &(loop->size), > loop->steps, loop->funcdata); > UFUNC_CHECK_ERROR(loop); > break; > > Note that UFUNC_CHECK_ERROR calls PyErr_Occurred. That doesn't seem > thread safe to me. Or maybe there is something special about that > function I'm missing. Check the definition of the macro. It only calls PyErr_Occurred if the obj variable is non-zero on the loop structure, indicating an OBJECT-array loop. In that case, the NPY_LOOP_BEGIN_THREADS does not actually release the GIL either.
I'm still bothered by the fact that moving the check fixed ticket #733 on python2.6, whereas in python2.5 the error was caught, just too late to be useful. I'm also not sure why the x |= x loop goes through a buffer loop. With a nice contiguous array it should have gone straight through the fast loop.
It could be the need for data-type conversion as well. I need to catch up with the ticket to understand what is going on, though. -Travis