Add possibility to configure the way tasks are spawned

[tomaka]

The async_std::task::Builder and async_std::task::spawn methods assume that some kind of environment is present (ie. a background thread pool) where to spawn tasks.

async-std/src/task/pool.rs

Lines 172 to 192 in 532c73c

	static ref QUEUE: Sender<Job> = {
	let (sender, receiver) = unbounded::<Job>();
	for _ in 0..num_cpus::get().max(1) {
	let receiver = receiver.clone();
	thread::Builder::new()
	.name("async-task-driver".to_string())
	.spawn(|| {
	TAG.with(|tag| {
	for job in receiver {
	tag.set(job.tag());
	abort_on_panic(|| job.run());
	tag.set(ptr::null());
	}
	});
	})
	.expect("cannot start a thread driving tasks");
	}
	sender
	};

Crates that provide some sort of hidden environment generally provide a way to configure how it works. Example of what I mean:

• https://doc.rust-lang.org/nightly/std/panic/fn.set_hook.html
• https://docs.rs/futures-timer/0.3.0/futures_timer/struct.TimerHandle.html#method.set_as_global_fallback
• https://docs.rs/log/0.4.8/log/fn.set_logger.html
• Tracking issue for std::io::set_panic and set_print rust-lang/rust#31343

Similarly, I think async_std should provide some sort of set_task_spawner function that allows configuring how that works.

The use-case I have in mind is the browser environment, where you want to drive tasks by using spawn_local (which is implemented using setTimeout).

[yoshuawuyts]

@tomaka on phone right now — but would perhaps an acceptable short-term solution to your issue be to allow async-std to work in the browser? Specifically task::spawn.

[tomaka]

short-term solution

It's not urgent at all!
My browser experiments work by merging everything into a single future. I don't spawn anything in the background at the moment.

[sdroege]

See also #79, which is kind of related but broader.

[yoshuawuyts]

As this is mostly already covered by #79, I'm going to go ahead and close this issue. We should continue to gather input on what folks want to configure and report it back in #79.

Thanks all!