[issue31654] ctypes should support atomic operations

[Daniel Colascione]

Daniel Colascione <dancol at google.com> added the comment:

On Sun, Oct 1, 2017 at 11:12 AM, Antoine Pitrou <report at bugs.python.org>
wrote:

>
> Antoine Pitrou <pitrou at 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 <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________