Antoine Pitrou <pit...@free.fr> added the comment: > 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.
There's no reasonable formula for computing an absolute switching interval from the current "check interval" number. Besides, as I said, there's no demonstrated reason to change the interval with the new GIL. > * 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 Well, if you don't use any threads you don't have to change the setting in the first place :-). You might want to do it in order to "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this is unnecessary with the new GIL, since the interval is ignored when there's only one thread running. > Turning the existing APIs into no-ops is certainly not a good > idea, since that will change application performance for both > use cases. The new GIL will change performance far more anyway. Trying to simulate the old behaviour is doomed to failure. If we want to keep the current performance characteristics, we'd better not backport the new GIL (which I'm fine with by the way). ---------- _______________________________________ 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