-----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

Reply via email to