search

python-trio / trio

Trio – a friendly Python library for async concurrency and I/O
https://trio.readthedocs.io
Other
6.19k stars 339 forks source link

Should we expose RunVars directly? #481

Open njsmith opened 6 years ago

njsmith commented 6 years ago

This is a pretty low-priority issue, but something to think about before 1.0 anyway:

Once #478 is merged, we'll have a few RunVar objects used directly in trio itself: the default thread limiter exposed via trio.current_default_worker_thread_limiter, and the hostname resolver and socket factory test hooks exposed via trio.socket.set_custom_hostname_resolver and trio.socket.set_custom_socket_factory.

For the last two in particular, the public functions are basically the simplest possible set/get APIs; they exist solely to hide the clunky old RunLocal API. Now we have RunVar, which is ... basically the same thing, a more usable API for setting/getting these kinds of variables. So maybe we should just... expose that? So e.g. set_custom_hostname_resolver would become custom_hostname_resolver.set?

The worker thread limiter is a little more subtle. Right now we don't expose any way to change the underlying default limiter object itself; you can adjust the number of simultaneous threads, by getting the object and mutating its total_tokens attribute, but you can't replace it wholesale with some other policy. Is there any use case for other policies? I guess you could make a C# thread pool style policy that admits threads after a delay that's proportional to the current pool size... probably anything fancy like this would be better handled by overriding the limiter for specific calls to run_sync_in_worker_thread, though. OTOH, exposing a RunVar isn't particularly problematic either. (I guess it would let you override the default with one that's just broken, but I don't think there is any particular danger here beyond any other sort of broken code.)

Fuyukai commented 6 years ago

I don't see any problem with simply exposing them as public; it also means easy resetting is possible (by saving the token, doing the calls, and restoring it later) whereas the tokens are silently discarded with the set_() functions (at least currently).