nnorwitz at gmail.com
Fri Aug 24 18:01:25 CEST 2007
On 8/24/07, Hrvoje Nikšić <hrvoje.niksic at avl.com> wrote:
> On Thu, 2007-08-23 at 11:57 -0700, Neal Norwitz wrote:
> > > "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.
> I thought other "IO-bound" threads (the sections that "allow threads")
> could also run in parallel. Otherwise what is the point of
Right. I looked at this with Jeffrey Yasskin and agree that a lock is
needed for f_fp. The fix is ugly because it's needed around all
accesses to f_fp and there are a ton of them. Some are with the GIL
held and others when it isn't.
I would be fine with the much simpler approach in the patch I sent
(assuming the patch is finished). It doesn't completely address the
problem, but does make the race condition much, much smaller. Part of
the reason I'm ok with this is that in 3.0, all this code has already
More information about the Python-Dev