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