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 ?
- 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.
- 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 new feature would solve my programmability issue. I think that this
case will happen a lot.