Luc Le Blanc wrote:
Logan wrote:
But, if you are working with an appinfo block, then I think you can be pretty confident that the LocalID is a handle and not a pointer, so you should be safe doing the MemPtrUnlock().
Is there some release I have to do then after I unlock the pointer I got from locking the LocalID received with DmDatabaseInfo for the AppInfo block? Somehow, I have the impression this is the culprit.
I personally don't do much to my appinfo stuff because I have the system just manage the categories in it, but I think the MemPtrUnlock() is all you need to do. Since this is sort of an uncertain area, I think I would probably just try to discover what to do empirically, by building a version of your app that simply skips everything to do with updating the appinfo, then soft-reset the device and run that. I do agree, by the way, that this area of the API is a little odd. If simply letting go of a handle is OK for an appinfo block, then why is it not OK for a regular record or resource, i.e. why do DmReleaseRecord() and DmReleaseResource() exist? Conversely, if it's not OK to just let go of the handle without calling DmReleaseRecord() or DmReleaseResource(), then why is it OK to just unlock the pointer to the appinfo block? I suppose maybe the answer is that the app info handle gets released automatically up when you close the database.
Does the API Ref recommendation that "The application should call DmReleaseResource() as soon as it finishes accessing the resource data." really important if the said resource is in my own PRC? I do it systematically, but I'm wondering about the usefulness of it.
It seems it would be really important on NVFS devices, at least. As I understand it, DmReleaseResource() and DmReleaseRecord() are how the system knows that something no longer need to be in DBCache. So it would certainly be good practice. On the other hand, I recall that DBCache handles record databases and resource databases differently (it loads/saves resource databases as a whole, whereas it loads/saves individual records of record databases), so maybe the situation is different. In fact, looking at an old version of the limited OS source, it looks like DmReleaseRecord() does a lot whereas DmReleaseResource() does very little, in fact essentially nothing. In particular, DmReleaseRecord() has to worry about the busy bit, the dirty bit, and the database's modification number. These is where I am getting beyond my depth with hotsync knowledge, but I'm guessing that record databases sync only the records that have changed, while resource databases sync the whole database if it changes (if they sync it at all?). If I'm on the right track with this, I think this means that resource databases and record databases have more differences than I thought, i.e. it's not just a matter of how the records are keyed. This could even explain why DBCache handles the two types of databases differently. Going out on a speculative limb here, if DmReleaseResource() isn't really doing much (and applications can skip it without noticeable negative effects on older devices, even though it is technically a bug not to match every DmGetResource() with a release), then it doesn't make a very good place for the NVFS implementation to hook into in order to be informed when resources are still in use. Ergo, there probably is no reasonable place to hook into for resource databases, and NVFS has to live with being unable to treat resource databases' records as individual units. So, if all my speculation is correct, then I think my conclusion is that not doing DmReleaseResource() is against the rules, but you can get away with it because other people have been getting away with it, so even though it's against the rules, all devices that want good compatibility have to let you get away with it. Or to put it another way, it is a rule, but it may have become an unenforceable rule. But I would still follow it... :-) - Logan -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
