[issue31654] ctypes should support atomic operations

[Daniel Colascione]

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

On Sun, Oct 1, 2017 at 2:01 PM, Antoine Pitrou <report at bugs.python.org>
wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Le 01/10/2017 à 21:51, Daniel Colascione a écrit :
> >
> >> 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.
>
> That's even more specialized than I expected...
>

Huh? Both are very generic.

>
> > It's still faster than waiting several milliseconds for the GIL.
>
> Are you talking about https://bugs.python.org/issue31653? If so, it's
> just waiting for an appropriate PR to be filed.
>

This is a separate issue. That's about thrashing around less when we take a
lock. This issue is about process A not having to wait on process B to
schedule a thread in order to perform a simple operation on memory that
both processes own.

>
> > 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.
>
> That's a compiler-dependent compiler intrinsic (or perhaps a whole range
> of them, given there are different widths to cater for), an API wrapping
> it, plus some documentation and tests, that we have to maintain until
> the end of time (at least nominally).
>

It's trivial and easy to support conditionally. SCM_RIGHTS is "specialized"
and not supported on all systems, yet it's in stdlib.

>
> > 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".
>
> It was determined at the time that the use cases for these justified the
> effort of maintaining them in the stdlib. For a couple of these (such as
> "determining the type of a sound file" or even an NNTP client), I expect
> the decision would be different nowadays :-)
>
> Perhaps other core developers will disagree with me and agree to include
> (i.e. review, maintain) this functionality.  I simply am not convinced
> it deserves being included, but that's not a veto.
>

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue31654>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________