Windows support - time.sleep()?

[Redundancy]

In your commit "This doesn't need to be linux-only" you pull in libc, which is not present on my system (I assume it's part of GLibC).

I wonder however, why you can't use threading.Timer or time.sleep? It ought to have a resolution of at least 16ms on windows, but according to http://stackoverflow.com/questions/1133857/how-accurate-is-pythons-time-sleep could potentially be higher.

This could potentially make things work in vanilla Python without extra dependencies, even just as a cross platform fallback, and 16 samples a second seems fine to me for many uses.

Perhaps there's a good reason for not doing this though, I just don't know enough about it, so wanted to ask.

[bdarnell]

The change involving the linux-only comment (7112355) added support for mac and probably the BSD family; windows support wasn't even considered because windows doesn't support the setitimer call that the whole idea is built around. time.sleep measures real time, which generally isn't what you want for profiling (although we do have some of the drawbacks of real-time-mode anyway due to python's policy of only sending signals to the main thread). There is no way to approximate setitimer's more accurate profiling and virtual modes with cross-platform functions (although I suppose it could be used as a fallback if you don't mind the limitation of only running in "real" mode)

[Redundancy]

I ask because I have a product that is stuck on windows that I would like to be able to profile in production, but no good way of doing it. Given a lack of other options, I'd imagine anyone locked in to that platform would accept a less accurate fallback over nothing.

If I were to try it and create a pull request that used sleep on windows only, would you be likely to accept it?

[bdarnell]

Yeah, I'd be willing to accept a PR for windows support; this will probably require some refactoring to move all interaction with the signal module out of the collector itself.