On 2020年12月29日 02:20:45 +0900 Inada Naoki <[email protected]> wrote: > On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou <[email protected]> wrote: > > > > On 2020年12月28日 11:07:46 +0900 > > Inada Naoki <[email protected]> wrote: > > > > > > Additionally, if we introduce the customizable lazy str object, it's > > > very easy to release GIL during basic Unicode operations. Many third > > > parties may assume PyUnicode_Compare doesn't release GIL if both > > > operands are Unicode objects. > > > > 1) You have to prove such "many third parties" exist. I've written my > > share of C extension code and I don't remember assuming that > > PyUnicode_Compare doesn't release the GIL. > > It is my fault that I said "many", but I just pointed out possible > backward incompatibility. Why I have to prove it?
Because most C extension code is far from that level of micro-optimization, so I doubt you'll find much code that deliberately relies on such an obscure implementation detail. > > 2) Even if there is such third party code, it is clearly making > > assumptions about undocumented implementation details. It is therefore > > ok to break it in new versions of CPython. > > But it should be considered carefully, because these APIs are not > releasing GIL for a long time. > And this type of change do not cause just a simple crash, but very > rare undefined behaviors in multithreaded complex applications. > For example, borrowed references in the caller can be changed to other > objects with same size because memory blocks are reused. > It is very difficult to notice and reproduce. Agreed, but that's a general problem with the C API (the existence of borrowed references and the fact that most C API calls can silently release the GIL, even as a side effect of object (de)allocation). It's also why it's better for most use cases to something like Cython. Regards Antoine. _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/TL5BTMLGC57TSN35MRMNTYP7RRGH47N6/ Code of Conduct: http://python.org/psf/codeofconduct/