Add multithreading to libFLAC #634
Conversation
ktmf01
changed the title
ktmf01
force-pushed
the
pthread2
branch
3 times, most recently
from
6675c2a
to
7ff207f
Compare
ktmf01
force-pushed
the
pthread2
branch
2 times, most recently
from
eb9a588
to
ccd6af6
Compare
This should improve multithreading throughput
Also, don't rely on pthread_cancel anymore
This scales the number of active threads back when threads have to wait for work too often
Fuzzing with memory sanitizer gave out-of-memory failures
ktmf01
force-pushed
the
pthread2
branch
2 times, most recently
from
ca291d7
to
fa59edd
Compare
|
A lively discussion with test results, comparisons and suggestions can be found here: https://hydrogenaud.io/index.php/topic,124437.0.html |
|
This seems to only implement threading via pthreads even for windows, e.g. autotools/cmake check pthreads unconditionally. Is that really the intention? (I know mingw-w64 has pthread implementation, but still...) |
|
Yes. This has been extensively tested for Windows on mingw-w64. Could you explain what you think is wrong with that? |
The extra dependency on the pthread dll whereas win32 apis could be used directly. But that's an administrative decision, so I won't fight it. |
|
I don't know what you mean with administrative. I would think to use the win32 api's directly would mean adding quite a bit of code, because those APIs can't be used in the same way pthreads can be used? That code would get little CI coverage and no fuzzing coverage, so I'd rather not do that. |
No description provided.