task sleep

[jesse99]

There needs to be a way to put a task to sleep. Currently there is libc::sleep which is awful because it causes the thread to sleep which will often affect multiple tasks, and uv::sleep which is a bit annoying because it drags in libuv.

Unless it's easy to drop in a lighter weight task sleep perhaps the answer, for now, is to have a task::sleep which delegates to uv::sleep.

[brson]

I have always expected to use uv for sleeping. The current interface exposes the IoTask, which sleepers will almost never care about.

The downside is that, at least as currently implemented, there is a large amount of overhead (it may even currently involve task spawning). I would be curious to hear proposals for implementing sleep more efficiently.

[bblum]

in kernels, sleep tends to be implemented with the guarantee that the task gets scheduled "some hopefully short time after" the requested time has passed.

this means that a simple/naive implementation would simply deschedule the task, and the sched loop could simply check a timer each run_single_turn to wake up tasks (and instead of doing pthread_cond_wait when it's out of jobs, it would itself sleep if it had a sleeping task). this would work just fine when a system is otherwise idle, and be pretty simple to implement too.

in the presence of compiler-inserted yield checks (#524) I believe this would have no downside. in their absence, though, this means that a sleeping thread might "starve" if the other tasks on its thread do lots of computation between yield points... and it might be more useful to make the list of sleeping tasks be scheduler-global, so any sched_loop could pick it up (probably shouldn't implement this without also properly implementing work-stealing - #3095).

on the whole, though, i don't think that using #3367's approach (spawning a task into a single-threaded scheduler and then directly invoking sleep) would be that bad (especially for now, especially considering the relative implementation ease). if we are already invoking sleep, is the extra cost of spawning a new task really too much?

[bblum]

I guess maybe one concern with the single-threaded new-scheduler-spawn method is that it allocates memory.

[graydon]

We have two mechanisms: one that blocks the thread (libc) and one that doesn't (uv). We don't need a third. If uv isn't fast enough, that's an optimization problem, not a need to add a third (unless measurement shows we absolutely can't make it fast enough, for some reason).