From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: GH replacement proposal (includes a bit of Unicode) Date: Sun, 25 Apr 2004 09:54:23 +0200 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <408B6EAF.4030008@dirk-herrmanns-seiten.de> References: <877jw87hjv.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1082878369 22373 80.91.224.253 (25 Apr 2004 07:32:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 25 Apr 2004 07:32:49 +0000 (UTC) Cc: guile-devel@gnu.org, Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 25 09:32:38 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BHe7y-0000SZ-00 for ; Sun, 25 Apr 2004 09:32:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BHe7Y-0001Rh-KA for guile-devel@m.gmane.org; Sun, 25 Apr 2004 03:32:12 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BHe6q-0001MK-NZ for guile-devel@gnu.org; Sun, 25 Apr 2004 03:31:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BHe6I-0000sd-Pi for guile-devel@gnu.org; Sun, 25 Apr 2004 03:31:27 -0400 Original-Received: from [212.227.126.184] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BHe6B-0000jS-Cf for guile-devel@gnu.org; Sun, 25 Apr 2004 03:30:47 -0400 Original-Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BHe68-0000jA-00; Sun, 25 Apr 2004 09:30:44 +0200 Original-Received: from [80.131.40.213] (helo=dirk-herrmanns-seiten.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BHe68-0007F5-00; Sun, 25 Apr 2004 09:30:44 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.devel:3648 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3648 Marius Vollmer wrote: > Rob Browning writes: > > > On a related note, in many cases, I suspect all the user may really > > need is a cheap way to copy some offset + size chunk of the data > > into their own buffer, especially when dealing with homogeneous > > uint8 arrays. If so, then it might make sense to provide a set of > > functions that can do that, handling whatever locking and memcpying > > is needed. > > > Yes, that would be a good addition. However, I'd still want to have > the low-level functions (scm_lock_heap, scm_l_* etc.) available. You > can use them to code the more convenient variants, but it is > unlikely that we can provide convenience variants for all cases. I can not understand at all, why we should introduce such a concept from the start: The non-locking related API allows users to do all they could want to do. Locking is only introduced to avoid performance problems due to memory allocation when extracting string contents. This early optimization is done at the wrong time. Before we don't even have an implementation without locking available, we don't know how much of a problem the memory allocation really is for a typical application. If it later appears that the real performance problem comes from the fact that our internal memory organization of strings is bad, we are stuck. If it later appears that the global locking introduces more performance problems than it solves, we are stuck. Further, to really be able to rate the design of the global heap locking, I need more information about how it would be implemented: What exactly would happen at the moment one thread calls scm_lock_heap? What is the performance penalty for additional thread-switches due to the global locking? How much is it compared to the expected performance gain for the typical application? Which parts of guile are affected by introducing the global locking concept? In general, I think the proposal is a step in the right direction. My suggestion is to start with the non-controversial stuff and provide users with an API that allows them to do everything they want, and postpone the performance optimization issues. As far as I see it, the global locking could be added later without influence on the rest of the API. Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel