Cute feature of erts on Windows

[Shawn Pearce]

I found this one the hard way, but fortunately I had read the source a
few weeks ago and knew about it, so I at least knew to look for it and
I didn't spend that much time on it.


A fool might want to create a mutex using CreateMutex, and then set it
using driver_select(my_port, my_mutex, DO_READ, 1) such that when the
mutex is available and the emulator has won the lock, the driver gets
its read_ready function called.  In theory this looks great, as the
emulator can keep running while waiting for the lock to be granted,
especially if the lock might be in use for long periods by other
threads/processes.

Once the emulator grabs the lock, it cannot be released!  Because the
emulator waits for the event using a background thread, ReleaseMutex will
fail to release the lock, because the driver is running on a different
thread than the one which won the lock through the WaitForMultipleObjects
call.


This goes to say two things:  One should always check return values (I
was not checking the return value of ReleaseMutex, assuming it world
just work) and the erts documentation should point out that developers
should not wait on mutexes, but instead use a semaphore, which let
the event waiter thread win the semaphore, but the driver thread
release it.

-- 
Shawn.

  A fool and his money are soon popular.