Re: more futures

[Mikael Djurfeldt]

On 12/21/05, Andy Wingo <address@hidden> wrote:
> Semi-replying to my own mail,
>
> On Wed, 2005-12-21 at 17:10 -0500, Andy Wingo wrote:
> > From then on out I can't call nsum any more. Perhaps threads assigned to
> > futures are not being gc'd properly.
>
> If I run (gc) it's fine. I caught the error at
> threads.c:scm_spawn_thread; pthread_create is returning an error. I'm
> not really sure what's causing the error, though -- i.e. what is the
> resource that is under contention.

Referring to my previous reply, I'd guess the OS is complaining
because you are trying to allocate too many threads.  Probably, the
main reason for complaining is that the stack space per thread is
eating too much of main memory.

> Furthermore there is some odd behavior here:
>
> guile> (make-future (lambda () (throw 'foo)))
> $4 = #<future #<procedure #f ()>>
> In thread:
> uncaught throw to foo: ()
> guile> (future-ref $4)
> [hangs]
>
> One would expect future-ref to raise the same exception; the thread
> finished, the future knows it; there's no reason to hang there. Raising
> an exception makes more sense.

When a new future is created by fetching it from the future cache and
initializing it, it's dynamic context (dynamic root, wind chain,
fluids etc) needs to be re-initialized. Also, Guile developers should
look over the exception handling to check that it works properly in
futures (I would have thought it did---as long as the dynamic context
initialization is done).