On Thu, Oct 31, 2013 at 7:07 AM, Ben Kloosterman <bkloo...@gmail.com> wrote:
>> >> The big issue here then is really that rust tasks can be pre-empted, and >> therefore you can't guarantee that *any* function is free from blocking >> (which means you can't assign it a large stack, since it may go to sleep >> while holding it). IMO co-operative tasks (by default) is worth considering >> as a solution here. >> > > re Co operative tasks , I have bad memories of 3.X apps which could lock > the whole OS/GUI when in a tight loop ? Certainly not a solution for > single core systems , even on dual system it can be an issue. On quad+ > there is some merit but history has shown every addin /lib will use as > many resources as they can ( eg flash add animations ) and not yield > willingly. It can be done but you need to check tasks with a schedule > service task and if they dont behave pre-empt / reduce priority. > > > > I do think there definitely needs to be a solution for actually pre-emptible threads (whether backed by OS or done in the language runtime). E.g. you might put third party code in there if it's something that will run for a long time. I'm just not sure that most tasks within your own code needs to be pre-empted to ensure they don't misbehave - you're in charge of them, make sure they don't soak up cycles for an unbounded period of time to avoid having starving the other tasks (the language RT would probably spawn up more OS threads if that happens, I'd imagine, which gets you back into the same area of eating up virtual address space by having more OS threads than HW threads, each of which has a dedicated "large stack" to run non-blocking tasks on)! -- Sebastian Sylvan
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
