On Dec 14, 12:46 pm, Omry Yadan <[email protected]> wrote: > from sqlite3-3.5.9/src/main.c line 31: > > int sqlite3_threadsafe(void){ return SQLITE_THREADSAFE; } > > osimons wrote: > > The sqlite.threadsafety read setting seems to be set to 1 in source, > > reagardless of compile settings
Right, I'm sure it is in there somewhere - it is just not exposed in any Python information structure that I can find. Having to read C libs directly will complicate our own setup. That is still also just one part of the puzzle, as the frontend also matters. It works really well for you as things are compiled the right way, and you use WSGI daemon mode with one process serving through threads - essentially same strategy as all Windows frontends (Apache mpm_nt never creates more than one process to serve requests). However, if you use any frontend that forks to serve connections, the pool is a very bad idea - essentially making new copies of the pool (and connections) in new processes that have no means of coordinating their actions. And, as the db code is essential to any Trac loading, it will likely be populated with connections before requests start coming in. Forking and db pooling will be unpredictable. So, the check as it stands is the lowest common denominator of "trusted" pooling. Question is, how can we improve the checks to also include other safe situations? One idea that springs to mind is to start off non-pooled, but as requests come in we can read req.environ wsgi settings that on my (OSX/Apache 2.2.10) mod_wsgi daemon setup shows as: wsgi.multiprocess: False wsgi.multithread: True wsgi.run_once: False However, on my mod_python test setup it reads: wsgi.multiprocess: True wsgi.multithread: False wsgi.run_once: False For the total set of versions/platforms/settings deemed as safe, we could then check and turn on pooling for the process when first request is made. :::simon https://www.coderesort.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
