|
If i understand properly, basicaly, it means that any filter which needs buffer and allocate them once for all in constructor and so free them in destructor (which is normaly the best and correct way to do) will be screwed with MT mode, because for the same instance/variable filter, several getframe can be runned in the same time (which doesn't occur in not MT mode), and so both will access the same buffer and corrupt each other.
Issue is not because of PlanarFrame hack, it's deeper, meaning that for being MT compatible, if you need buffers, you have to allocate and free them in GetFrame... Honestly, i don't like the idea, but don't know if actualy there is a better solution.
We are hitting here something deeper. It's design restriction. If you want your filter being MT compatible, you have design restrictions. But again, it's specific to this MT mode.
A better solution, but again hitting MT specific design, would be that constructor allow, once for all, several buffers, the number of buffer being decided by the number of multi-thread, and each GetFrame get some "Thread number" information, and so the correct buffer is used by the getframe. Again, the MT scheduler must assure that there is never two getframe of the same filter instance with the same number.
Anyone of course can discuss, agree, disagree (but in that case explain me why and where i'm wrong) with this.
|