Scott Vallery wrote: > have you considered 'threading'? This sounds like something that you need to > create a thread to do. Creating a thread should then allow you to set > parameters to wait until one process completes and switch back and forth.
Yes, threads would make cooperation easier. SQLite has a shared cache mode, allowing multiple threads to share a single database connection and all the database cache information therein. Piggybacking on this shared database connection, SQLite's unlock-notify callback system can be used to let one thread notify (wake up) another when it's time to pass the baton. All this existing capability would take minimal integration effort on my part. I wish this were available to me. The fact is threads are completely unsuited for my actual task. I specifically need to inject SQLite database access into a wide variety of existing programs that, for the most part, only talk to each other via the filesystem. I can't very well rewrite all of them to know and love each other like longtime couples who subconsciously complete each other's sentences. Thus, I must rely on SQLite's built-in cross-process synchronization, which on Unix-like systems is implemented using fcntl(), which in turn is implemented using the filesystem. SQLite is extensible enough to allow me to plug in alternative locking implementations. For example, I could write a concurrency server to which each instance of SQLite would connect (via Unix domain socket, TCP, etc.), through which access would be coordinated. But before doing anything drastic like that, I want to see how far vanilla SQLite will take me. I might end up having to do that once I am forced to start running on NFS, given its broken locking. All that being said, I am well familiar with threads, which is why I prefer to avoid them for all purposes besides leveraging additional CPU cores, and even then I will do my best to have the additional threads do little more than computation. Grudgingly, I will also use them to work around broken APIs with functions that don't return for a long time, such as DNS resolvers and certain GUI toolkits, but that is not a happy situation. As Richard Suchenwirth said, threads are for hangmen. ------------------------------------------- CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
