From: "meister(a)reservoir.com" <meister(a)reservoir.com>
Date: Wednesday, May 21, 2014 at 10:55 AM
To: Romain Cledat <romain.e.cledat(a)intel.com>
Cc: Technical OCR <ocr-dev(a)lists.01.org>
Subject: Self-destuctible DB
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.
- 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).
- 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
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
- 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
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
If we wanted to sound fancy, we could even call it a basic form of garbage
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?
This new feature would solve my programmability issue. I think that this case
will happen a lot.