You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an external application already has its own threading technology (be it a thread-pool or w/e), it is hard to wire it to OpenImageIO's own thread-pool.
If we enable multi-threading with the oiio threadpool we get overthreading because a threadpool is a centralized way of managing threads workload.
If we disable multi-threading for OIIO using oiio-threads, we then get no multi-threading for things like parallel_convert_image.
OIIO being a library, it should be able to operate with another application's thread-pool, so that we get the best performance possible out of OIIO.
I tried to hack around and modify the thread-pool API so it could be inherited by the application and we could replace the default thread-pool by forwarding calls to our own threading mechanism, but the API of the thread-pool being complicated with templated functors makes it impossible to achieve.
The other way around would be to use OIIO's thread-pool as main threading backend of the application but we do not want that as there is better suited threading technologies available.
I did the same with OpenEXR's thread-pool and it works well because their thread-pool API is essentially very simple with just a "addTask" function and their simple Task and TaskGroup classes.
The text was updated successfully, but these errors were encountered:
When an external application already has its own threading technology (be it a thread-pool or w/e), it is hard to wire it to OpenImageIO's own thread-pool.
If we enable multi-threading with the oiio threadpool we get overthreading because a threadpool is a centralized way of managing threads workload.
If we disable multi-threading for OIIO using oiio-threads, we then get no multi-threading for things like parallel_convert_image.
OIIO being a library, it should be able to operate with another application's thread-pool, so that we get the best performance possible out of OIIO.
I tried to hack around and modify the thread-pool API so it could be inherited by the application and we could replace the default thread-pool by forwarding calls to our own threading mechanism, but the API of the thread-pool being complicated with templated functors makes it impossible to achieve.
The other way around would be to use OIIO's thread-pool as main threading backend of the application but we do not want that as there is better suited threading technologies available.
I did the same with OpenEXR's thread-pool and it works well because their thread-pool API is essentially very simple with just a "addTask" function and their simple Task and TaskGroup classes.
The text was updated successfully, but these errors were encountered: