From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19505 invoked by alias); 14 Aug 2013 10:28:45 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Received: (qmail 19491 invoked by uid 89); 14 Aug 2013 10:28:45 -0000 X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_NO,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 Received: from limerock01.mail.cornell.edu (HELO limerock01.mail.cornell.edu) (128.84.12.99) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 14 Aug 2013 10:28:44 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id r7EASf3s010832 for ; Wed, 14 Aug 2013 06:28:42 -0400 Received: from [192.168.1.5] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id r7EAScbc002527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Aug 2013 06:28:39 -0400 Message-ID: <520B5BC7.4060306@cornell.edu> Date: Wed, 14 Aug 2013 10:28:00 -0000 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: [ANNOUNCEMENT] Uploads for 12 August References: <520A01DF.1040208@alice.it> <520A21B1.8060503@alice.it> <520A3EF6.80700@cornell.edu> <520A7654.3080207@users.sourceforge.net> <20130813182653.GA4315@calimero.vinschen.de> <520AAC65.1090708@cornell.edu> <20130814081003.GA29227@calimero.vinschen <20130814091656.GE4315@calimero.vinschen.de> In-Reply-To: <20130814091656.GE4315@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00028.txt.bz2 On 8/14/2013 5:16 AM, Corinna Vinschen wrote: > On Aug 14 10:10, Corinna Vinschen wrote: >> On Aug 13 18:00, Ken Brown wrote: >>> On 8/13/2013 2:26 PM, Corinna Vinschen wrote: >>>> On Aug 13 13:09, Yaakov (Cygwin/X) wrote: >>>>> On 2013-08-13 09:13, Ken Brown wrote: >>>>>> Yaakov, is there any chance that you could patch Glib to do the >>>>>> equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an >>>>>> emacs issue. It would affect any GTK application that provides its own >>>>>> malloc rather than using Cygwin's malloc. (But emacs is probably the >>>>>> only such application in the distro.) >>>>> >>>>> Given that the only programs which seem to be *practically* affected >>>>> by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't >>>>> have yet), and using G_SLICE=always-malloc apparently affects >>>>> performance, I don't think that would be an appropriate solution. >>>>> >>>>> For now, I think you'll have to add a wrapper script. >>>> >>>> Can anybody of you explain to me what the actual underlying problem is? >>>> I mean, why this error message: >>>> >>>> ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes >>>> (alignment: 512): Function not implemented >>>> >>>> What function is not implemented? Is that something we can fix, >>>> perhaps in the Cygwin DLL? >>> >>> It's memalign, or at least that's what it was in 2007. See >>> >>> http://cygwin.com/ml/cygwin/2007-02/msg00678.html >> >> So it's using its own malloc but we don't support overriding other >> functions besides malloc/realloc/calloc/free. >> >> In theory we could do that in future. We still have room for 10 (x86) >> resp. 12 (x86_64) pointers in the per_process structure, which could be >> used for this purpose. This would only require applications which need >> this feature to be rebuilt with the next Cygwin version providing these >> pointers. > > More precisely, they have to be rebuild using crt0.o from the next > Cygwin release, and they would have to run under the next Cygwin > release. If you omit one step, you're back to the current behaviour. > >> But we shouldn't waste those unused slots either, so the number of >> overridable functions should be kept small. In theory we have mallopt, >> mallinfo, posix_memalign, memalign, and valloc. >> >> I guess we can skip mallopt and mallinfo since they are pretty >> seldomly used in user-provided malloc implementations. >> >> Memalign is an old, deprecated function, so I wonder why it's used at >> all. GSlice should use posix_memalign instead. Yaakov, is there an >> option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. >> Anyway, that would be three extra pointers in the per_process structure, >> for memalig, posic_memalign, and valloc, and we could get rid of the `if >> (!use_internal) set_errno(ENOSYS);' in those functions and rather call >> the user provided functions then. >> >> Does that make sense? Yes. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/