[racket-dev] [plt] Push #22421: master branch updated

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Sat Apr 9 21:00:07 EDT 2011

On Sat, Apr 9, 2011 at 7:50 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Sat, 9 Apr 2011 19:00:20 -0500, Robby Findler wrote:
>> On Sat, Apr 9, 2011 at 6:46 PM,  <mflatt at racket-lang.org> wrote:
>> > 8570033 Matthew Flatt <mflatt at 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.

Oh, nice.

> 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.

Yes, certainly! Thanks.


Posted on the dev mailing list.