//net code is already using the TaskScheduler, and likely to keep growing more such dependencies. Right now reaching those dependencies on cronet will result in a crash. (Prohibiting the TaskScheduler in //net code does not seem like the correct path forward).

The iOS build of cronet is already initializing (albeit not shutting it down) the TaskScheduler, due to a dependency introduced a while ago.

There are concerns with enabling TaskScheduler for cronet:

  * Is initialization/teardown process-wide? Cronet is a library and could in theory be loaded with other libraries that use a TaskScheduler.

  * Tune down the number of threads used. The default thread provisioning seems heavy-weight for cronet's purposes. A more appropriate policy might be to limit to 1-2 extra threads total, created lazily, and reclaimed shortly after becoming idle.