Martin v. Löwis wrote: >Todd Miller <jmiller@stsci.edu> writes: > > > >>Point taken. What I'm really proposing is this: >> >> > >Thanks for detailing this proposal. I now agree with your assumption >that missing release calls might cause problems; I'd expect that they >indeed will cause problems in many applications. > Thanks for reading it. > >The main issue is the interaction with ParseTuple, the 's', 'w', and >'t' converters invoke a buffer operation, after which (under your >proposal) the object is locked, there is no corresponding release >call, and no place to put such a call. > I've used this aspect of PyArg_ParseTuple, but forgot about it. I was thinking that you're right, the original object is "gone", we're stuck. But... it's still (in all probability) lying around in the arg tuple, so some sort of PyArg_ReleaseBuffers is possible. It could even be a near-carbon-copy of the PyArg_ParseTuple which "lost" the object to begin with, to make the book keeping easy: PyArg_ParseTuple(args, "iw#Os", &someInt, &writeableptr, &writeablesize, &someobject, &readableptr) becomes: PyArg_ReleaseBuffers(args, "iw#Os") at exit time. The parse spec defines which parts of the tuple to release, and which not to release. Anything which is not w,s, or t gets skipped. w,s,t are released. With this call, it becomes possible to "fix" the PyArg_ParseTuple case. Incidentally, does PEP-298 solve this now? (I think the answer is no. PEP-298 is just using a different approach to "phased introduction" by leaving the original problem fully exposed in backwards compatability mode. Or am I missing something here too?) > >So, once you have passed an array to some C function expecting a >char*, you cannot extend the array anymore. > Well, this does sound bad, but I was assuming the core and library would be "fixed" at the first introduction of locking, and the only problem would be with non-conforming extensions. I now think that "lock violations" might be better handled using the warning framework, defaulting to a one time warning. Todd
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4