From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: problem with futures? Date: Thu, 22 Dec 2005 10:56:20 +0100 Message-ID: <66e540fe0512220156s47532d1co5841d7eef2e898de@mail.gmail.com> References: <1135203013.4312.40.camel@localhost.localdomain> Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1135253736 2808 80.91.229.2 (22 Dec 2005 12:15:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2005 12:15:36 +0000 (UTC) Cc: Mikael Djurfeldt , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu Dec 22 13:15:35 2005 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EpPM6-0003sS-JG for guile-devel@m.gmane.org; Thu, 22 Dec 2005 13:15:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpPLP-0005e9-5N for guile-devel@m.gmane.org; Thu, 22 Dec 2005 07:14:51 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EpNIB-0005y4-T3 for guile-devel@gnu.org; Thu, 22 Dec 2005 05:03:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EpNEk-0005WN-C2 for guile-devel@gnu.org; Thu, 22 Dec 2005 04:59:52 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EpNCO-00052P-5S for guile-devel@gnu.org; Thu, 22 Dec 2005 04:57:24 -0500 Original-Received: from [64.233.162.194] (helo=zproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EpNBU-0004Yb-6A for guile-devel@gnu.org; Thu, 22 Dec 2005 04:56:28 -0500 Original-Received: by zproxy.gmail.com with SMTP id x3so431694nzd for ; Thu, 22 Dec 2005 01:56:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dYkeYR25rDdJ7MvXQaIFV6Q8kP+b8vPW8TAiSxSwrq16hPlJljhlJyIt3CsHRQa55xYdTcFEWwXbpSVBNvY5jAN9lJ1Pi4/QCEz2QmcZMeiQWFNK58W0F8PMktz5Y2K1I7y3vAS2cQljgNYbg+EofSpk/xbRaNVzTkwCCXisEsg= Original-Received: by 10.65.137.4 with SMTP id p4mr122779qbn; Thu, 22 Dec 2005 01:56:20 -0800 (PST) Original-Received: by 10.65.97.4 with HTTP; Thu, 22 Dec 2005 01:56:20 -0800 (PST) Original-To: Andy Wingo In-Reply-To: <1135203013.4312.40.camel@localhost.localdomain> Content-Disposition: inline X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5547 Archived-At: Andy, I started implementing futures, but have not been doing any Guile development since some time. The basic mechanism is there, but the implementation is incomplete.=20 The major omissions are associated with exactly the two problems you bring up. These known bugs are: the handling of the future cache needs to be better, and, (even more important) the initialization of the dynamic context for a new futures is currently not done at all. The last point is a bug (the implementation is incomplete) which has to be fixed before any release. I've pointed this out before. On 12/21/05, Andy Wingo wrote: > (define (nsum n) > (apply + (let ((x 1)) > (par-map (lambda (y) (set! x (1+ x)) (+ y x)) > (make-list n 0))))) > > I get this: > > guile> (nsum 100) > $1 =3D 5150 > guile> (nsum 100) > $2 =3D 5150 > guile> (nsum 100) > $3 =3D 5150 > guile> (nsum 100) > > Backtrace: > In current input: > 5: 0* [nsum 100] > 1: 1 [apply # ... > 1: 2* (let* ((x 1)) (par-map (lambda (y) (set! x #) (+ y x)) > (make-list n 0))) > 1: 3 [par-map # (0 0 0 0 0 0 0 0 0 ...)] > In /opt/guile/share/guile/1.7/ice-9/threads.scm: > 52: 4 [map # ... > 53: 5* [apply # # ...] > In unknown file: > ?: 6 [map] > ?: 7* [map # (0 0 0 0 0 0 0 0 0 ...)] > ?: 8* [# 0] > In /opt/guile/share/guile/1.7/ice-9/threads.scm: > 55: 9* (future (apply mapper (proc . arglists))) > > /opt/guile/share/guile/1.7/ice-9/threads.scm:55:20: In expression > (future (apply mapper #)): > /opt/guile/share/guile/1.7/ice-9/threads.scm:55:20: Cannot allocate > memory This is probably simply that your OS/memory can't handle more than 100 pthreads (including the memory space for the stack of each thread). > >From then on out I can't call nsum any more. Perhaps threads assigned to > futures are not being gc'd properly. Futures are cached for re-use. This makes overhead of futures lighter than that of ordinary threads. Currently, there is no mechanism for clearing the future cache. As long as the application is using a reasonable number of thread (relative to what the OS can cope with), there is no big reason to clear it. However, for robustness against bugs and extreme use, there should be a set of rules for clearing it.=20 For example, it could be cleared if no futures have been created within the last 10 ms. Also, one could have some upper limit on the number of futures being cached. For now, I will not work further on that code. To the Guile developers I suggest that you do what you want. Fix it, or back out the future feature entirely. M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel