Charles R Harris wrote: > > > On Sat, Apr 26, 2008 at 11:21 AM, Travis E. Oliphant > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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 _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
