
report at bugs
Jul 26, 2008, 6:07 AM
Post #20 of 68
(461 views)
Permalink
|
|
[issue3139] bytearrays are not thread safe
[In reply to]
|
|
Martin v. Löwis <martin[at]v.loewis.de> added the comment: > (1) are you sure it is safe not to INCREF the obj pointer in the > Py_buffer? Yes, that's the semantics of the current buffer interface, and I cannot see a flaw in it. When you call getbuffer, you certainly hold a reference, and it is your obligation to hold onto this reference somehow. So it is definitely safe (if properly documented). > It would seem more logical for PyBuffer_FillInfo to > INCREF the obj, and for PyBuffer_Release to DECREF it and set it to NULL. Perhaps. I cannot quite see what undesirable consequences that might have - feel free to develop and test an alternative patch that takes that approach. > (2) is it necessary to call directly bf_getbuffer & the like or is there > a higher-level API to do it? There is PyObject_GetBuffer and PyObject_ReleaseBuffer, but it is not higher-level. I need to check the function pointers, anyway (to determine whether the object supports getbuffer and requires releasebuffer or not), so calling them directly is the right level of abstraction (IMO). > (3) didn't you forget to convert "PyArg_ParseTuple(args, "s#iO:sendto", > [...])" in sock_sendto? True. > (4) is it really necessary to do a special case with PyString_Check() > rather than rely on the string type's getbuffer method? That's what the code always did (for s#). It would be possible to eliminate that case, yes. _______________________________________ Python tracker <report[at]bugs.python.org> <http://bugs.python.org/issue3139> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
|