Re: [OCR-dev] Self-destuctible DB

wrote:

Hello, Answers inline. Thanks, Romain From: &quot;meister(a)reservoir.com&quot; <meister(a)reservoir.com&gt; Date: Wednesday, May 21, 2014 at 10:55 AM To: Romain Cledat <romain.e.cledat(a)intel.com&gt; Cc: Technical OCR <ocr-dev(a)lists.01.org&gt; Subject: Self-destuctible DB Romain, I just had a conversation about how data blocks are managed in OCR and we have two related questions, based on the fact that the runtime (allocator) keeps track of acquires/releases and registered EDTs. Vincent's question: - Right now, when a destroy is called on a DB, the allocator doesn't perform the destruction if there exist EDTs that are registered with the DB. Shouldn't this instead be an error case ? Ideally, yes. In other words, the EDT that calls the destroy should not be able to be called until all users of the DB have actually finished (i.e.: there should be a hard dependence between those EDTs and the EDT that calls the destroy). This could be changed to be more strict (and for now maybe just point out a big fat warning to make sure apps don’t break but well written ones shouldn't). Benoit's question: - In programs we generate, some tasks create DBs that will be used by descendants of the tasks only. Since the children tasks are executed asynchronously, it is hard for the application writer to know when the DB can be destroyed. Current bad solutions are: - Make the EDT that creates the DB a finish EDT, wait for all its children to finish, and destroy the DB. Why is this a bad solution? You would create a "parent" EDT that is a finish one and a "clean-up" EDT that would execute when everything is done. - Create special EDTs to destroy the DBs, pass their guids to all the descendants, and use a latch event on these special EDTs to know when none has acquired or is registered with the DB (this is error-prone and a pain in the neck) - Put all the DB destroys after the enclosing ocrWait(). This is sub-optimal in terms of memory footprint, and it also assumes the presence of an ocrWait :D It looks like, since the allocator is keeping track of registered EDTs and acquire/releases, it would be relatively easy to support a special type of DBs that gets automatically destroyed when it is registered with and acquired by no EDTs. If we wanted to sound fancy, we could even call it a basic form of garbage collection :) This is feasible. We would have to add something about registrations as opposed to actual use which would have use-cases for other things too (this is currently not done but could be implemented). We have been trying to move to a system where we try to track features and bugs a bit more. Could you file a feature request on Trac about this? Thanks, Romain This new feature would solve my programmability issue. I think that this case will happen a lot. Thanks, - Benoit