Ah, I see, thanks. It is less painful than the other solutions, but less elegant (and more convoluted in terms of code generation) than the self-destructible DBs. And it creates EDTs that may just run one dbDestroy.

On Wed, May 21, 2014 at 3:40 PM, Cledat, Romain E <romain.e.cledat@intel.com> wrote:
We are probably talking about a different solution then. I was talking about something like this:

EDT "start":
- Creates a parent finish EDT "A"
- Creates a clean-up EDT "B"
- Links "A"'s output event to "B"

EDT "A":
- A creates a whole bunch of Dbs and packs their GUID into another DB that it passes to "B" (satisfies a dependence)
- "B" will only execute when all of "A"'s children are done

EDT "B":
- "B" executes, gets the DB passed by "A" and cleans up all the Dbs created

This has no wait but maybe I am misunderstanding the problem :).


From: "meister@reservoir.com" <meister@reservoir.com>
Date: Wednesday, May 21, 2014 at 12:09 PM

To: Romain Cledat <romain.e.cledat@intel.com>
Cc: Technical OCR <ocr-dev@lists.01.org>
Subject: Re: Self-destuctible DB

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.