Marc-Andre Lemburg <m...@egenix.com> added the comment: Antoine Pitrou wrote: > > Antoine Pitrou <pit...@free.fr> added the comment: > >> * Instead of deprecating the set/getcheckinterval APIs, convert the >> arguments passed to these to the switch interval. The new APIs >> set/getswitchinteral are then not needed. > > This is certainly not a good idea. The semantics are different, which is the > reason why I created a separate API in the first place instead of recycling > the old one. > > Actually, there should be hardly any reason to want to change the interval > with the new GIL implementation. It was required with the old GIL due to the > fact that counting opcodes is a very poor way of estimating wall clock > durations.
Applications currently use those APIs for two reasons: * they use lots of threads and need to make sure that they all run more often than they do with the default settings e.g. to make them respond faster to external inputs: in such a case, they use a low check interval number * they don't use any threads and thus don't need to check for other threads at all or only rarely: in such a case they use a large check interval number While the semantics are different, the result is similar and the actual numbers used are usually determined by experiment or rough estimate - noone expects the APIs to provide any kind of exact timing and it's not needed either. Turning the existing APIs into no-ops is certainly not a good idea, since that will change application performance for both use cases. Esp. the second use case (single threaded process) is a rather common one in Python - using multiple processes is often the more scalable approach for Python applications, than relying on multiple threads. >> Note that gettimeofday() et al. are rather slow APIs on most systems > > In my measurements under Linux it seemed to be as fast as clock_gettime() > actually. But I don't know about other systems. I didn't want to complicate > the patch (with several different paths) more than seemed necessary. Right, but clock_gettime() provides a better resolution. Both APIs are relatively slow, so if you call them often, it's better to go with a different mechanism such as one built on CPU performance counters. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7753> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
