You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA #45376
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/gpshead'closed_at=<Date2008-01-19.18:43:03.078>created_at=<Date2007-08-27.07:42:48.833>labels= ['interpreter-core', 'type-feature']
title='bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA'updated_at=<Date2008-01-19.18:43:03.077>user='https://github.com/gpshead'
I've converted _bsddb.c to use the py3k buffer API for all data and keys
it takes as input. All tests now fail with this error:
BufferError: Cannot make this object read-only.
This presumably results from this call:
PyObject_GetBuffer(obj, view, PyBUF_LOCKDATA)
I need to lock the data so that the GIL can be released during database
operations (I/O).
Allowing bytes objects to have an immutability or readonly bit (internal
or otherwise) has been a recent topic on the python-3000 mailing list;
that would allow bytes' buffer API to satisfy this GetBuffer LOCKDATA
request...
Attaching the most recent patch (minor update from the second one i sent
to the python-3000 mailing list to initialize ob_readonly_exports = 0 in
the appropriate places).
Current mailing list discussion is pointing out that the name LOCKDATA
means something other than what the existing PEP-3118 description implies
and that we may want to modify the pep to support more obviously named
things such as READ_LOCK, and EXCLUSIVE or similar... here's a link to
the current thread:
changed the title [-]bytes buffer API needs to support PyBUF_LOCKDATA[/-][+]bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA[/+]on Sep 12, 2007
Anyways, no the _bsddb.c changes that I checked in do not cause a
problem because I checked them in using PyBUF_SIMPLE.
Until PEP-3137 is implemented the possibility of hidden data corruption
due to mutable bytes objects being modified while an IO library that
releases the GIL is using them remains.
Feel free to close this bug in favor of something that just tracks the
PEP being implemented.
Feel free to close this bug in favor of something that just tracks the
PEP being implemented.
Eh, it can stay open as a reminder to double-check everything is fine
once PEP-3137 goes in. It's really up to you since the bugs is
assigned to you. =)
Activity
gpshead commentedon Aug 27, 2007
I've converted _bsddb.c to use the py3k buffer API for all data and keys
it takes as input. All tests now fail with this error:
BufferError: Cannot make this object read-only.
This presumably results from this call:
I need to lock the data so that the GIL can be released during database
operations (I/O).
Allowing bytes objects to have an immutability or readonly bit (internal
or otherwise) has been a recent topic on the python-3000 mailing list;
that would allow bytes' buffer API to satisfy this GetBuffer LOCKDATA
request...
gpshead commentedon Aug 30, 2007
I sent an initial patch to the mailing list. Its too late to be ready
for 3.0a1; I'll fix it up next week.
gpshead commentedon Sep 12, 2007
Attaching the most recent patch (minor update from the second one i sent
to the python-3000 mailing list to initialize ob_readonly_exports = 0 in
the appropriate places).
Current mailing list discussion is pointing out that the name LOCKDATA
means something other than what the existing PEP-3118 description implies
and that we may want to modify the pep to support more obviously named
things such as READ_LOCK, and EXCLUSIVE or similar... here's a link to
the current thread:
http://mail.python.org/pipermail/python-3000/2007-September/010325.html
[-]bytes buffer API needs to support PyBUF_LOCKDATA[/-][+]bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA[/+]brettcannon commentedon Oct 7, 2007
All the tests pass for me, Gregory. Were the failures with some patch
you had only locally?
gpshead commentedon Oct 8, 2007
This bug will be taken care of by PEP-3137
http://python.org/dev/peps/pep-3137/ being implemented.
Anyways, no the _bsddb.c changes that I checked in do not cause a
problem because I checked them in using PyBUF_SIMPLE.
Until PEP-3137 is implemented the possibility of hidden data corruption
due to mutable bytes objects being modified while an IO library that
releases the GIL is using them remains.
Feel free to close this bug in favor of something that just tracks the
PEP being implemented.
brettcannon commentedon Oct 8, 2007
On 10/7/07, Gregory P. Smith <report@bugs.python.org> wrote:
[SNIP]
Eh, it can stay open as a reminder to double-check everything is fine
once PEP-3137 goes in. It's really up to you since the bugs is
assigned to you. =)
tiran commentedon Jan 19, 2008
*ping* Can this issue be closed?