I find the solution bad because it creates task syncrhonizations
unnecessarily (for reasons that are unrelated to the program's semantics).
And the simple way of implementing this implies the use of ocrWait, which
is not recommended on FSIM.
I'll file a feature request on Trac.
On Wed, May 21, 2014 at 2:47 PM, Cledat, Romain E <romain.e.cledat(a)intel.com
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 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
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.