1

Reading through the comments of another question, I see that there is risk of encountering race condition(s) when using the GetWindowThreadProcessId Windows API method. How big of a risk is this?

Allow me to provide background into what I am attempting. I am writing a timekeeping app in C# for my own personal use. My intent was to have the app detect (via Win API calls) when the active window has changed so that I can log time against the application being used. I have already located code that detects when the active window changes; now I am trying to determine the process associated with that window. I have located several posts on SO that point to GetWindowThreadProcessId as the solution, but as I mentioned there seems to be a potential issue in using it. If GetWindowThreadProcessId is not a safe way to go, then I am open to other alternatives.

My hope was to keep the code wholly in C#, but I am not (completely) opposed to moving parts of it into C/C++ if necessary.

Thanks!

Community
  • 1
  • 1
Kenneth K.
  • 2,987
  • 1
  • 23
  • 30

1 Answers1

3

The race is unavoidable. There's no API that can atomically do what you want.

But it's a rather benign race. What can go wrong? The window is closed just before you ask about it. So you get an error and then try again. All you need to do is be aware of the race condition and check for and handle errors gracefully.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Honestly, that's what I was thinking. An hWnd doesn't change so long as the window remains open, correct? If so, then I would think that the only time I should be concerned about this when closing a window. – Kenneth K. Mar 08 '13 at 00:39
  • 1
    Yep, that's right. Handle errors well and it's no problem. Windows tries hard to avoid re-using handles. You'll have no probs. – David Heffernan Mar 08 '13 at 00:44