WaitForSingleObject succeeds for incorrect event

[blem14]

• Expected behavior and actual behavior.
  WaitForSingleObject(ev, 0) seems to succeed (result==0) if event other than the ev gets set.
  Same happens for WaitForSingleObject(ev, 0, alert) (doesn't matter if alert is set or not).
  Issue doesn't occurr every time, but I was able to reproduce it many times.
  Setting wait time to 1 didn't produce errors for me, might be going into that "waiting state" makes it happen less often.

  I realize it might be on Windows API's side, but maybe it's not and you'd be able to figure it out 😄
  I've also found stackoverflow thread of similar problem, but it got replied that it had bad code in general (might be an incorrect judgement though).

  Severity depends on use-case, in mine it was to interrupt threads and sync some data.

• Steps to reproduce the problem.
  Running below code should interrupt thread running foo(1), but interrupts foo(2) in more than 50% runs.
  Screenshots here to showcase the issue.

  from win32event import SetEvent, CreateEvent, WaitForSingleObject
  from threading import Thread
  
  d = {
      1: {"interrupt": CreateEvent(None, False, False, "interrupt"),
          "end": CreateEvent(None, False, False, "end")},
      2: {"interrupt": CreateEvent(None, False, False, "interrupt"),
          "end": CreateEvent(None, False, False, "end")}
      }
  
  def foo(x):
      while WaitForSingleObject(d[x]["interrupt"], 0):
          pass
      SetEvent(d[x]["end"])
      del d[x]
    
  def bar(y):
      Thread(target=foo, args=[y]).start()
  
  print("before", d)
  
  bar(1)
  bar(2)
  SetEvent(d[1]["interrupt"])
  # give it a second to interrupt, then check `d`

• Version of Python and pywin32
  Python 3.6.8 + pywin32 300 (same thing on 224)

[mhammond]

These are thin wrapper around the windows API - it would be almost impossible for win32api to cause the wrong event to be triggered. This is a support request - see https://github.com/mhammond/pywin32/blob/master/README.md#support

[blem14]

The section you point out clearly says Feel free to open issues for all bugs (or suspected bugs) in pywin32., so calling it a "support request" is just being a prick.
Don't expect me digging in your code, when I can raise an issue regarding suspected bug and let you decide if it is something you can fix.
It might not be on your side, but that's still a bug report being rejected, not magically becoming support request.

Anyway, if you say bug is on Windows API side, that's fine, issue's there in case someone else had the same problem.