larryhastings / gilectomy

Gilectomy branch of CPython. Use "gilectomy" branch in git. Read the important, short README below!
Other
527 stars 43 forks source link

Current refcount tracking idea seems to be incomplete for borrowed references #32

Open JustAMan opened 8 years ago

JustAMan commented 8 years ago

I think that I understand correctly that currently what you changed is basically removed global locking and made inc- and decref's be atomic operations. If that is true then there's (I think) a possible data race issue when an object is borrowed.

Consider the following idea of example:

  1. Code borrows an object from some other object, say, takes a reference to the first item of a list, e.g. x = PyList_GetItem(lst, 0)
  2. Before that code could call an incref on x some other parallel thread at that moment replaces first item of that list with something else, e.g. PyList_SetItem(lst, 0, y).
  3. That setting calls a decref on x which might be called before first thread calls its incref.
  4. This could lead to x reaching zero refcount and being destroyed, and then first thread tries to increase refcount for x. Bam! Segfault :(

I think that probability for this issue is really low, but it's possible to exist. I don't think I have any ideas on how to fix this issue, though, so I'll just drop a note here and maybe someone else would have some idea.

To sum up, there's a possibility of a data race leading to possible crash because using some API that borrows a reference and then incrementing a reference is not atomic.