[issue8426] multiprocessing.Queue fails to get() very large objects
Changes by Philip Semanchuk : -- nosy: +osvenskan ___ Python tracker <http://bugs.python.org/issue8426> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35813] shared memory construct to avoid need for serialization between processes
Philip Semanchuk added the comment: Hi all, I'm the author of `posix_ipc` on which some of this code is based. I'd be happy to sign a contributor agreement in order to erase any concerns on that front. -- nosy: +osvenskan ___ Python tracker <https://bugs.python.org/issue35813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35813] shared memory construct to avoid need for serialization between processes
Philip Semanchuk added the comment:
> On Feb 23, 2019, at 10:40 AM, Giampaolo Rodola'
> wrote:
>
>
> Giampaolo Rodola' added the comment:
>
>> We are consciously choosing to not support an atomic "create or attach".
>> This significantly simplifies the API and avoids the valid concerns raised
>> around user confusion relating to that behavior (including the use of
>> different specified 'size' values in a race) but does not preclude our
>> potentially introducing this as a feature in the future.
>
> I understand that because of *size* we cannot solve the race condition issue
> unless the user uses some sort of synchronization mechanism. FWIW I bumped
> into this lib:
> http://semanchuk.com/philip/sysv_ipc/
> ...which provides two separate APIs to "create" and "attach":
>
>>>> SharedMemory("name", IPC_CREX)
>>>> attach("name")
>
> At this point I'm agnostic about the API, which is probably just a matter of
> personal taste (e.g. one may prefer a separate SharedMemory.attach()
> classmethod or a *mode* argument accepting "x" and "a"). I see that that lib
> use shmat() on attach and shmdt() on detach. I'm not sure if that makes a
> difference, just mentioning it because your implementation doesn't do that on
> close() and perhaps it should.
attach() and detach() are particular to SysV IPC which is different from the
POSIX IPC that’s being used here. There’s no need for attach() and detach()
with POSIX shared memory.
POSIX IPC is generally simpler than SysV IPC, in part because it was developed
after SysV IPC so the developers had the benefit of experience with the older
API.
Side note: I’m the author of the sysv_ipc package you found, as well as the
posix_ipc package.
--
___
Python tracker
<https://bugs.python.org/issue35813>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5725] process SysV-Semaphore support
Philip Semanchuk added the comment: I stumbled across this bug report while looking for an mmap-related issue. I thought I'd mention that I have a module for SysV IPC that's about a year old. Obviously it's not in the standard library, but it is pretty well fleshed out. It's in active use and I consider it fairly well debugged. It's for Python 2.x only. http://semanchuk.com/philip/sysv_ipc/ Hope this helps -- nosy: +osvenskan ___ Python tracker <http://bugs.python.org/issue5725> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5298] Inconsistency in C-API thread docs
New submission from Philip Semanchuk : The language in the threading API documentation is a little inconsistent. The section I'm talking about is here: http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock The GIL is variously referred to as "global lock", "interpreter lock", "global interpreter lock", "GIL", and simply "the lock". Given the infamy of the GIL, one might expect all of these to be equally clear. But as someone coding to this API for the first time, I had plenty to learn already and the need to ensure that all of these referred to the same singleton was distracting. This documentation begins, "The Python interpreter is not fully thread safe. In order to support multi-threaded Python programs, there's a global lock that must be held by the current thread before it can safely access Python objects. Without the lock..." My suggestion is to alter the second sentence to the following: "Without this lock (called the global interpreter lock, or GIL for short)" All subsequent documentation references to "interpreter lock", "global interpreter lock", and "lock" should be changed to "GIL". It would be nice if the API referred to it consistently (e.g. PyEval_AcquireLock() versus PyGILState_Ensure()) but that would require an interface change which is obviously out of the question. -- assignee: georg.brandl components: Documentation messages: 82365 nosy: georg.brandl, osvenskan severity: normal status: open title: Inconsistency in C-API thread docs versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5298> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5299] PyGILState_Ensure()/PyGILState_Release() documentation incomplete?
New submission from Philip Semanchuk : The threading API documentation might omit out some important information about the GIL. The GIL can be acquired by explicitly calling PyEval_AcquireLock(). One can also acquire the GIL by calling PyGILState_Ensure(). The latter differs from the former in that calling PyGILState_Ensure() when one already has the GIL will not create deadlock. This is implied; it would be helpful if this was explicitly stated. Likewise, I assume that the Nth call to PyGILState_Release() releases the GIL, where N = the number of calls made previously to PyGILState_Ensure(). But I don't know this and the documentation doesn't make it clear. As a first-time user of the API, it makes me nervous to call PyGILState_Ensure() which acquires the GIL without knowing for sure that PyGILState_Release() releases it. I can't evaluate my code for logical correctness, and when dealing with threads and the GIL, neither can I be sure that timing-dependent bugs will show up in testing. As a result, my code feels fragile. I don't understand how the code works well enough to suggest better documentation. If nothing else, it would be useful to see something that promises that as long as each call to PyGILState_Ensure() is matched with a call to PyGILState_Release(), the GIL will take care of itself. -- assignee: georg.brandl components: Documentation messages: 82366 nosy: georg.brandl, osvenskan severity: normal status: open title: PyGILState_Ensure()/PyGILState_Release() documentation incomplete? versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20584] On FreeBSD, signal.NSIG is smaller than biggest signal value
Changes by Philip Semanchuk : -- nosy: +osvenskan ___ Python tracker <http://bugs.python.org/issue20584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
