This breaks the build for windows builds that don't use the pthreads_win32
library. Using the opaque pthread_t type like this is probably not a great
idea. Using PBD::pthread_name is another option that I've used elsewhere
that seems more useful.
For some backends the process thread can change (e.g.
switch coreaudio headphone + internal speakers)
If there are existing x-thread event calls this can lead to
the following situation:
1) SessionEvent::operator new
2) audioengine process thread change
3) SessionEvent::operator delete -> crash, wrong thread
SessionEvent::operator delete can safely push the event back to
the pool for later cleanup..
undo (n) where n > 1
redo (m) where m < n
new transaction.
Previously the redo list was left untouched.
This would lead to utter nonsense in the redo list.
AFAICT this never worked.
Expanded API splits apart some CrossThreadPool functionality, and provides
access to current pool status information (available(), total(), used(), pending_size())
The infinite loop would happen if the 2 supplied paths were on different Windows drives - for example if one was on drive C:\ and the other on drive E:\
I don't think this new test will be detrimental to the other platforms but if it is, we could easily separate it out with a '#ifdef PLATFORM_WINDOWS' directive.
These changes are MSVC specific and shouldn't affect the other builds.
(incidentally, libpbd already offers a function called 'fast_log2()'. Not sure if that could have been used instead...)
This shows that PBD::Timer is pretty much identical in terms of timing and CPU
usage as Glib TimeoutSources.
They also show the differences on Windows when setting the minimum Multimedia Timer
resolution using timeBeginPeriod
This was a very clever attempt to fix a non-problem. If the platform doesn't have enough file descriptors available
then the platform is broken and we're not going to hack around trying to fix it.
