At Sat, 9 Apr 2011 19:00:20 -0500, Robby Findler wrote: > On Sat, Apr 9, 2011 at 6:46 PM, <mfl...@racket-lang.org> wrote: > > 8570033 Matthew Flatt <mfl...@racket-lang.org> 2011-04-09 17:10 > > : > > | futures: more bug fixes, make `touch' safe > > | - bug fixes are related to allocation and runstack space > > | - a `touch' within a future can complete before the `touch'ing > > | future is itself `touch'ed > > Just to make sure I understand: this is only in the case that the > touch within the future is touching some finished future or a future > that is going to finish without being unsafe, right?
Yes. If a future is touched by more than once (I doubt we have such programs, so far), then there's a slight generalization: If the touched future involves an unsafe operation, but it is also touched via the runtime thread, then the touching future can run after the runtime touch completes. There's probably room for improvement in the scheduler. Specifically, if a future is touched and it's far back in the queue, it might be better to move it to the front of the queue, so that the original future can continue sooner. Meanwhile, my explorations for `touch' uncovered the real sources (I think) of crashes on my machine yesterday: * Lightweight continuations were sometimes captured during an attempt to synchronize for allocation (not useful, and not supported by the JIT). * Application of a lightweight continuation needed to make sure that the new runstack has enough extra space (i.e., the original host of the continuation checked to make sure it had enough space, so the new host needs to have at least as much space). Fixing those bugs was probably more useful than the `touch' changes. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
