29.03.2011 21:57, Mark Murphy пишет:
On Tue, Mar 29, 2011 at 1:43 PM, Kostya Vasilyev<[email protected]> wrote:
There is no leaked database connection with Content Providers.
Yes, there is, at least by my definition (close() not being called).
By this definition, every program running in a non-GC environment has a
memory leak, which would be a very interesting point of view.
I never said a memory leak. I said a leaked database connection.
I know you didn't.
It was an example of a resource (memory) not being released by
application code, relying on the OS or the runtime to clean it up upon
process termination -- which is was happens to an open database file.
To me, a leak is where the use of some resource grows over time and has no
chance of decreasing. The resource in question may be memory, open files,
DMA buffers, etc.
To me, a leak is something that is allocated and not released. The
"release" could be manually (e.g., calling close()) or automatically
(e.g., finalizers in a GC environment).
http://en.wikipedia.org/wiki/Resource_leak
That definition is overly academic for my taste - it would too, consider
almost any C/C++ program to have a memory leak.
Besides, not closing a database is not specific to content providers.
An application that shares a database object among different components
might keep it open as well.
Which, if never closed, would represent a leak of a database connection.
Which would have nothing to do with content providers.
That presumes that there is no SQLite logic in a database close() that
is important. One hopes that is the case, given the way content
providers are implemented.
It seems safe to not close a SQLite database, based on empirical evidence
supported by some ten million Android devices worldwide, all having some
databases and content providers, including those built into the platform.
Those same ten million Android devices worldwide are also using
AsyncTask, which Romain Guy indicated has flaws severe enough to cause
them to drop it back to a single-thread pool in an upcoming Android
release, which may have fairly substantial backwards-compatibility
issues.
So? Bugs happen and code changes happen. Creating and maintaining a
framework is really hard, you can't anticipate everything up front.
IOW, while I agree that empirical evidence beats no evidence, it is
not a guarantee that everything is all coming up roses, either.
Besides empirical evidence, see this comment made by the author of SQLite,
D. Richard Hipp:
http://www.mail-archive.com/[email protected]/msg01280.html
Program crashes, OS crashes, and power failures should not
corrupt an SQLite database.
This too is a positive sign.
I just don't know... It's like, he and one other guy wrote the thing :)
It is entirely possible that I am merely a curmudgeon. Three decades
of dealing with resource corruption due to poor coding practices --
like opening databases and not closing them -- will do that to a guy.
Sorry. Get a drink?
--
Kostya Vasilyev -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" 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/android-developers?hl=en
