On 12/21/05, Andy Wingo <[EMAIL PROTECTED]> 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
