Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@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. 

Just use some conversion formula, e.g. switching interval in micro
seconds = constant * byte code check interval. We can then determine
a constant to match todays CPU performance.

Given the inexact nature of the check interval that's a very
reasonable formula.

> Besides, as I said,
> there's no demonstrated reason to change the interval with the new GIL.

Didn't I just point out two use cases ?

Perhaps I'm missing some feature of the new GIL. Is there some
documentation for it somewhere ?

>> * 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.

Hmm, how do you determine that only one thread is running ?

What if an extension uses threads that are not under Python
control, e.g. when embedding the JVM or when using a CORBA
ORB ?

>> 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).

I don't follow you.

If an application currently sets the check
interval to a low value, Python should switch to other threads
more often, ie. the switch interval needs to be low.

If an application currently sets the check interval to a high
value, Python should switch to other threads less often, ie.
the switch interval needs to be higher.

Both cases can be mapped to the switch interval, so why not
do it ?