Skip to content

bytes buffer API needs to support read locking and/or PyBUF_LOCKDATA #45376

Closed

Description

@gpshead
BPO 1035
Nosy @brettcannon, @gpshead, @tiran
Files
  • bytes-readlock-via-lockdata-gps02.patch.txt
  • 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 = <Date 2008-01-19.18:43:03.078>
    created_at = <Date 2007-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 = <Date 2008-01-19.18:43:03.077>
    user = 'https://github.com/gpshead'

    bugs.python.org fields:

    activity = <Date 2008-01-19.18:43:03.077>
    actor = 'gregory.p.smith'
    assignee = 'gregory.p.smith'
    closed = True
    closed_date = <Date 2008-01-19.18:43:03.078>
    closer = 'gregory.p.smith'
    components = ['Interpreter Core']
    creation = <Date 2007-08-27.07:42:48.833>
    creator = 'gregory.p.smith'
    dependencies = []
    files = ['8420']
    hgrepos = []
    issue_num = 1035
    keywords = ['patch']
    message_count = 7.0
    messages = ['55333', '55456', '55838', '56260', '56263', '56264', '60168']
    nosy_count = 3.0
    nosy_names = ['brett.cannon', 'gregory.p.smith', 'christian.heimes']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue1035'
    versions = ['Python 3.0']

    Activity

    1. gpshead commented on Aug 27, 2007

      @gpshead
      MemberAuthor

      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...

    2. gpshead commented on Aug 30, 2007

      @gpshead
      MemberAuthor

      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.

    3. self-assigned this
      on Aug 30, 2007
    4. gpshead commented on Sep 12, 2007

      @gpshead
      MemberAuthor

      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

    5. 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
    6. brettcannon commented on Oct 7, 2007

      @brettcannon
      Member

      All the tests pass for me, Gregory. Were the failures with some patch
      you had only locally?

    7. gpshead commented on Oct 8, 2007

      @gpshead
      MemberAuthor

      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.

    8. brettcannon commented on Oct 8, 2007

      @brettcannon
      Member

      On 10/7/07, Gregory P. Smith <report@bugs.python.org> wrote:
      [SNIP]

      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. =)

    9. tiran commented on Jan 19, 2008

      @tiran
      Member

      *ping* Can this issue be closed?

    10. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)type-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions