RetroSearch Browse

Thu Aug 23 20:57:45 CEST 2007 · https://mail.python.org/pipermail/python-dev/2007-August/074276.html

On 8/23/07, Hrvoje Nikšić <hrvoje.niksic at avl.com> wrote:
> On Wed, 2007-08-22 at 21:32 -0700, Neal Norwitz wrote:
> >         Py_BEGIN_ALLOW_THREADS
> >         errno = 0;
> > -       ret = _portable_fseek(f->f_fp, offset, whence);
> > +       if (f->f_fp != NULL)
> > +               ret = _portable_fseek(f->f_fp, offset, whence);
>
> Doesn't this kind of code retain a race condition?  Since this is an

Exactly what I'm thinking.  That's why I said:

    I'm not convinced the attached patch is good enough though.

It definitely reduces the race and might fix the problem.

> "allow threads" section that runs with the GIL released, file_close
> might acquire the GIL and be running in parallel to this code.  If
> file_close sets f_fp to NULL after the "if" condition evaluates, but
> before the call to _portable_fseek completes, we still get a segfault.

However, the setting of f_fp to NULL happens with the GIL set, ie
while only one thread is running.  So I *think* (but I'm not sure) the
condition you mention is not possible.  Either way the fix seems
brittle.  (Also, the patch I attached was not complete.)

Also all this code has gone away in 3.0.

n

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-August/074276.html below:

[Python-Dev] Segfault