How come a cross-platform emulation layer for WaitForSingleObject and WaitForMultipleObjects API entry-points, based on condition variables & binary semaphores, manages to work significantly faster than the native Windows functions is beyond me. Sure, I only support event & thread objects, as opposed to the number of different object types the usual API supports, but..
Could it be the monitor thread which works as a spin-lock, if there’s at least one thread waiting? I could work around this, letting the CPU spend cycles on something more productive, but there’s a handful of thread race conditions that could backfire if I don’t handle them carefully.
I was initially worried that the Emerald’s performance on Linux would be a shame, if someone compared it to the Windows build’s. Turns out I may actually switch to the event emulation one day in the Windows world 🙂
The march for the Linux port carries on..