Daniel Colascione <dan...@google.com> added the comment: On Sun, Oct 1, 2017 at 11:12 AM, Antoine Pitrou <rep...@bugs.python.org> wrote:
> > Antoine Pitrou <pit...@free.fr> added the comment: > > Le 01/10/2017 à 20:04, Daniel Colascione a écrit : > > > > It's not that specialized. You might want atomic updates for coordinating > > with C APIs that expect callers to have this capability. > > That does sound specialized to me :-) Can you give an example of such a > C API? > The Linux futex protocol, as described in man futex(7), comes to mind. Maybe you want to manipulate C++ shared_ptr objects --- these objects also rely on atomic operations. For these facilities, you need atomic operations for *correctness*. Taking a mutex as an alternative is not an option because there is no C-side mutex to take. > > You don't need to provide all of those builtins. Users can build them in > > Python out of atomic-compare-and-exchange. Only compare and exchange > needs > > C support. It's not very much code. > > I'm assuming you're suggesting to write a loop with an > atomic-compare-and-exchange. Bytecode execution in CPython being slow, > it means you risk a lot more contention (and busy looping) than if the > primitive was written in C. Perhaps even a semaphore would be faster :-) > It's still faster than waiting several milliseconds for the GIL. Bytecode isn't *that* slow --- according to ipython, this operation should take a few hundred nanoseconds. Besides, in a JIT implementation, it'll be as fast as native code. > > > I have little interest in a separate PyPI module. I don't want to have to > > distribute custom-compiled extension modules. > > Understood, but that's not enough of an argument to put something in the > standard library... > > You might want to float your idea on python-ideas to see if you get > support from people who have a similar need: > https://mail.python.org/mailman/listinfo/python-ideas > > I don't understand the opposition to this feature request. It's a trivial amount of code (invoke a compiler intrinsic), makes the API more complete, and addresses a real, specific use case as well as some other hypothetical use cases. It costs nothing to add this functionality to the standard library. The standard library already includes a whole web server and HTTP client, a diff engine, various database engines, a facility for parsing email, an NNTP client, a GUI system, and a facility for "determin[ing] the type of sound [a] file". Why can the standard library include all of these facilities and not a simple facility for performing a very common kind of memory operation? Standard library support for this functionality is essential, as it's not possible to implement in pure Python. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31654> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
