more futures

more futures

[Andy Wingo]

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.

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.

Well these are just ordinary bugs I suppose. I'm looking forward to
playing more with guile 1.7.
-- 
Andy Wingo
http://wingolog.org/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: more futures

[Mikael Djurfeldt]

On 12/21/05, Andy Wingo <wingo@pobox.com> 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).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel