This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Daniel Colascione, amaury.forgeotdarc, belopolsky, davin, meador.inge, pitrou, rhettinger
Date 2017-10-01.18:12:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <2eb01833-012e-5f40-6727-780d0750980d@free.fr>
In-reply-to <CAKOZuev0xgNHPVhCsNMFD1fHG3r3qNNcdaNBadMex1mUGMdYWA@mail.gmail.com>
Content
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?

> 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 :-)

> 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
History
Date User Action Args
2017-10-01 18:12:08pitrousetrecipients: + pitrou, rhettinger, amaury.forgeotdarc, belopolsky, meador.inge, davin, Daniel Colascione
2017-10-01 18:12:08pitroulinkissue31654 messages
2017-10-01 18:12:08pitroucreate