> On 31. Aug 2017, at 01:37, Holger Freyther <
[hidden email]> wrote:
>
> Hi Eliot, Bert,
Hey!
> as part of reading the "goToSleep" primitive I had a look at Windows and the last time I dealt with win32 API was quite some time ago so maybe I am wrong but doesn't the time slice below look like a race condition? If not what am I missing?
> Couldn't we have lost the vmWakeUpEvent for the socket and then wait the full timeout? The history in Opensmalltalk-vm doesn't go far but couldn't we create the vmWakeUpEvent with the autoreset flag?
I looked at it again. First of all I think the MIDI Plugin should use an autoreset event for the midiInputEvent (as there is no call for ResetEvent).
Second I think we risk losing an event and then sleeping for the maximum timeout (and maximum might be indefinite in the future) but using autoreset might wake us up too early as well. It might be better to use autoreset but we can have something like this..
WakeUp
...
Smalltalk processes run
<- semaphore signalled for I/O
<- SetEvent...
Smalltalk processes run
IO will be handled
Sleep...
[Old call to ResetEvent that we should remove...]
WaitForMultipleObjects
So in this case we would wake-up besides all events already being handled. Any idea how to move forward? Shall we try to do the right thing and use autoreset and monitor CPU usage?
holger