-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/26/2010 07:47 PM, Bill Webster wrote: > I meant something that released all open files, blob handles, statement > handles etc., without terminating the process. > > I guess that this must've been considered and that there is a practical or > philosophical objection to it.
Igor gave the right answer to this - if you are in a state where you need to do that then what else have you lost track of? BTW it is extremely rare for any library to provide this kind of "pull the rug out from everything" functionality and there are many more issues as to what exactly should be cleaned up. For example what about VFS, collations, extensions, functions etc that you have registered - should they just leak or do you keep track of them? There are several alternatives. - - Use a language such as C++ where you have objects that clean up after themselves. You just need to release your C++ objects then. - - Use an even higher level language such as Python where my SQLite wrapper (APSW) provides the ability to close connections forcibly disconnecting any running statements. In addition builtin garbage collection in the language means the objects just go away if you stop referencing them. - - Make a child process and have it do your SQLite work. Talk to it over a pipe with commands and data. Kill the process and you are done. This also makes testing easier since you can make a mock child process that returns test data, deliberate errors etc. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwm2SAACgkQmOOfHg372QRG8QCfaMG4NHhpFqmA1V+ilB1VqjYn 2qAAoLMcA83T9Std9MvhN851+SJGJErm =pvv0 -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
