Hello, As far as I know in Rust, a thread (green or not) that enters an infinite loop without I/O is forever stuck. The only available option to stop it is to have the OS kill the process (CTRL+C).
In my day job, all our servers services are time-bounded and any that exceeds its time bound is killed. To do so requires one process per service for the exact same reason than Rust, which has the unfortunate effect of requiring a large memory footprint because "utility threads" (such as timers, and notably the watch-dog timer) are replicated in each and every process. The most common source of time-slips are disk accesses and database accesses which is covered by Rust under I/O, however I've already seen infinite loops (or very long ones) and there seems to be no way to protect against those. Of course one could recommend that such loops check a flag or something, but if we knew those loops were going to "diverge" we would fix them, not instrument them. I was hoping that with Rust (which already rids us of good-bye to dangling pointers & data races) we could move toward a single process with a lot of concurrent (green) tasks for better efficiency and ease of development, however the latter seems unattainable because of infinite loops or otherwise diverging code right now. I would thus also appreciate if anybody had an idea how to preempt a misbehaving task, even if the only option is to trigger this task failure; the goal at this point is to salvage the system without losing the current workload. -- Matthieu On Sat, Apr 12, 2014 at 11:04 AM, Jeremy Ong <[email protected]> wrote: > I am considering authoring a webserver (think nginx, apache, cowboy, > etc) in Rust. From a user point of view, mapping tasks (green) to web > requests makes the most sense as the tasks could be long running, > perform their own I/O, sessions, or what have you. It would also allow > the user to do per-request in memory caching. > > My main concern is obviously the cooperative scheduler. Given that the > mantra of Rust seems to be safety, I'm curious about how feasible it > would be to provide the option for task safety as well. Preemptive > scheduling provides two things: > > 1. If preemption is used aggressively, the user can opt for a lower > latency system (a la Erlang style round robin preemptive scheduling) > 2. Preemption of any sort can be used as a safety net to isolate bugs > or blocks in tasks for long running systems, or at least mitigate > damage until the developer intervenes. > > I noticed in issue 5731[1] on the repo, it was pointed out that this > was possible, albeit difficult. The issue was closed with a comment > that the user should use OS threads instead. I really think this > misses the point as it no longer allows preemption on a smaller > granularity scale. Could any devs chime in on the scope and difficulty > of this project? Could any users/devs chime in on any of the points > above? > > tl;dr I think preemptive scheduling is a must for safe concurrency in > long running executables at the bottom of the stack. Opinions? > > > [1] https://github.com/mozilla/rust/issues/5731 > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
