[Python-Dev] Re: sqlite3 module and thread-safe SQLite library
On 18/12/2019 00.56, Gregory P. Smith wrote: > > On Tue, Dec 17, 2019 at 12:30 PM Kacvinsky, Tom > mailto:[email protected]>> wrote: > > We ran into an issue where having the SQLite library built with > -DSQLITE_THREADSAFE=0, > but then the sqlite3 module (really, the _sqlite3.so0 crashing in > threading code. So I have > to ask if it is intended that the sqlite3 Python module always be > built with a thread safe > SQLite library. > > Thanks, > > Tom > > > Given your experience I think you've answered the question: Yes. But it > would be good if we could detect this at build time (is there a way to > do that?) and prevent the module from being built against the sqlite3 > library compiled in this unusual mode.. Threading support is required > in order to be a valid CPython platform, so all libraries used should be > aware of that. We have to detect the problem at run-time. Compile time is not sufficient. It's possible to compile Python with a thread-safe version of libsqlite3, then run Python with a unsafe version of libsqlite3. sqlite3 has two APIs to query thread safety and three different settings for threading: sqlite3_threadsafe() sqlite3_config() SQLITE_CONFIG_SINGLETHREAD SQLITE_CONFIG_MULTITHREAD SQLITE_CONFIG_SERIALIZED Only serialized is fully thread safe. I would start by checking that (sqlite3_threadsafe() == SQLITE_CONFIG_SERIALIZED). Christian ___ 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/W4T7E24TYDDH5ASVGLYYY4POJVUBJEYT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Thread argument for exc_info and public API
Hi there, I've been poking around the thread state API and error/exception handling, and there's something missing I'd like to see happening. The only way to retrieve the current exception is via sys.excinfo or PyErr_GetExcInfo in C. However, the issue is that they don't take a PyThreadState as argument, but use _PyThreadState_GET() to retrieve the thread state. That makes it impossible to retrieve the exception information for a different thread than the one calling the function. In order to retrieve the exception from *any* PyThreadState, the caller has to use _PyErr_GetTopmostException which takes a PyThreadState as argument — though that function is private and therefore not documented or usable in an external module (in theory at least). Should we make _PyErr_GetTopmostException public, or implement something different to retrieve the top most exception from a PyThreadState? Cheers, -- Julien Danjou # Free Software hacker # https://julien.danjou.info ___ 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/QVMFP76R35SXUIM2WPPVPV5XCVMKPDEB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
On Wed., 18 Dec. 2019, 5:51 am Tim Peters, wrote: > But there are also other optimizations in the current set > implementation, so "fine, add the doubly linked list to sets but not > to dicts" is only part of it. > > Which may or may not be possible to match, let alone beat, in an > ordered set implementation. A practical barrier now is that Python is > too mature to bank on loving optimizations _after_ a change to a core > feature is released. It's going to need a highly polished > implementation first. > > Starting with "collections.OrderedSet" seems like a reasonable idea, though - that way "like a built-in set, but insertion order preserving" will have an obvious and readily available answer, and it should also make performance comparisons easier. Cheers, Nick. __ > ___ 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/YBKI7QVH2X3RIBJQ76BCN3WCSJUDWGWM/ Code of Conduct: http://python.org/psf/codeofconduct/
