[Austizzle]

The GIL is per interpreter/process, so this wouldn't be related as far as I know.

The GIL only really kicks in if you use threads in a single process. Then, the GIL will only let one single thread do actual work at a time, and will trade off which thread gets to do work. The other threads can wait on IO stuff (web requests, the file system, etc) but they can't do number crunching or data processing at the same time.

That's a really interesting observation though, I wonder what _is_ causing your separate processes to sync up?

[refibrillator]

I’ve seen this before! Indeed it has nothing to do with Python or the GIL.

The OS scheduler has to execute M threads on N cpu cores, while also balancing competing priorities like latency and power usage.

Because each separate process uses a naive timer, the timings will drift slowly due to imprecision and small process scheduling delays etc.

After enough drift the timers will sync up by chance (harmonics), at which point OS scheduler incentives can lead the timings to “stick” together seemingly.

This may be a bit tangential, but I find it fascinating that there seems to be a mechanical version of this phenomenon with ancient roots - lookup spontaneous synchronization of pendulums.

[fireattack]

Thank you for your insight!

By the way, I asked about it previously on their repo before, if you're interested.

No replies yet though, since the development of the lib isn't very active to begin with.

https://github.com/dbader/schedule/issues/614