On 8/23/07, Hrvoje Nikšić <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
