---

yaml
---
r: 105892
b: refs/heads/auto
c: 91bed14
h: refs/heads/master
v: v3

Author: alexcrichton

[refs]

@@ -13,7 +13,7 @@ refs/heads/try3: 9387340aab40a73e8424c48fd42f0c521a4875c0
 refs/tags/release-0.3.1: 495bae036dfe5ec6ceafd3312b4dca48741e845b
 refs/tags/release-0.4: e828ea2080499553b97dfe33b3f4d472b4562ad7
 refs/tags/release-0.5: 7e3bcfbf21278251ee936ad53e92e9b719702d73
-refs/heads/auto: 80f92f5c5fedadd131842977c0b9b21806f3902f
+refs/heads/auto: 91bed14ca8085887a26d029d785d853ad2587718
 refs/heads/servo: af82457af293e2a842ba6b7759b70288da276167
 refs/tags/release-0.6: b4ebcfa1812664df5e142f0134a5faea3918544c
 refs/tags/0.1: b19db808c2793fe2976759b85a355c3ad8c8b336

branches/auto/src/libgreen/sched.rs

@@ -832,6 +832,20 @@ impl Scheduler {
     }
 
     pub fn maybe_yield(mut ~self, cur: ~GreenTask) {
+        // It's possible for sched tasks to possibly call this function, and it
+        // just means that they're likely sending on channels (which
+        // occasionally call this function). Sched tasks follow different paths
+        // when executing yield_now(), which may possibly trip the assertion
+        // below. For this reason, we just have sched tasks bail out soon.
+        //
+        // Sched tasks have no need to yield anyway because as soon as they
+        // return they'll yield to other threads by falling back to the event
+        // loop. Additionally, we completely control sched tasks, so we can make
+        // sure that they never execute more than enough code.
+        if cur.is_sched() {
+            return cur.put_with_sched(self)
+        }
+
         // The number of times to do the yield check before yielding, chosen
         // arbitrarily.
         rtassert!(self.yield_check_count > 0);