Daniel Colascione <dan...@google.com> added the comment: On Sun, Oct 1, 2017 at 2:01 PM, Antoine Pitrou <rep...@bugs.python.org> wrote:
> > Antoine Pitrou <pit...@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 <rep...@bugs.python.org> > <https://bugs.python.org/issue31654> > _______________________________________ > ---------- _______________________________________ 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
