preemptive scheduling

[thestinger]

I'm sure this would be very hard to implement and wouldn't be a good thing for all Rust code, but it is possible so I'm opening up an issue as a reference. I don't think having the compiler automatically insert yields into most loops would ever be an acceptable performance hit, so this is another alternative.

In a world without preemption, you can avoid blocking other tasks by assigning threads to tasks with CPU-bound loops or manually inserting scheduler yields. The garbage collector is task-local, so it's not going to be as big of an issue as it is in Go where one task can block garbage collection for the entire process.

[brson]

One alternate thing we can do if you want fairer scheduling is to run in a not-yet-implemented thread-per-task (or maybe more like scheduler-per-task) mode. It would cost some in context switching but you would get much better scheduling.

Additionally, we should be able to execute the schedulers themselves on segmented stacks. On Linux at least this would likely perform and scale amazingly well.

[graydon]

dupe of #3095 in the sense that "if we have work stealing and we always keep a spare thread around, we can let OS thread-preemption handle these cases by stealing all the work that would otherwise be starved".

[thestinger]

@graydon: Yeah, I don't think is worth implementing in a userland scheduler. If preemptive scheduling is wanted, it would be better to just use OS threads.