[Numpy-discussion] Threading question for Travis

[Travis E. Oliphant]

Charles R Harris wrote:
>
>
> On Sat, Apr 26, 2008 at 11:21 AM, Travis E. Oliphant 
> <oliphant at enthought.com <mailto:oliphant at 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