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(a)intel.com
We are probably talking about a different solution then. I was
about something like this:
- Creates a parent finish EDT "A"
- Creates a clean-up EDT "B"
- Links "A"'s output event to "B"
- 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
- "B" executes, gets the DB passed by "A" and cleans up all the Dbs
This has no wait but maybe I am misunderstanding the problem :).
From: "meister(a)reservoir.com" <meister(a)reservoir.com>
Date: Wednesday, May 21, 2014 at 12:09 PM
To: Romain Cledat <romain.e.cledat(a)intel.com>
Cc: Technical OCR <ocr-dev(a)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.