From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6800 invoked by alias); 14 Aug 2013 10:53:32 -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 6790 invoked by uid 89); 14 Aug 2013 10:53:32 -0000 X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED autolearn=ham version=3.3.2 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 14 Aug 2013 10:53:31 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 9B6D0520D3A; Wed, 14 Aug 2013 12:53:26 +0200 (CEST) Date: Wed, 14 Aug 2013 10:53:00 -0000 From: Corinna Vinschen To: cygwin-xfree@cygwin.com Subject: Re: [ANNOUNCEMENT] Uploads for 12 August Message-ID: <20130814105326.GF4315@calimero.vinschen.de> Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com 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> <20130814091656.GE4315@calimero.vinschen.de> <520B5BC7.4060306@cornell.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ls2Gy6y7jbHLe9Od" Content-Disposition: inline In-Reply-To: <520B5BC7.4060306@cornell.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Found: No X-SW-Source: 2013-08/txt/msg00029.txt.bz2 --Ls2Gy6y7jbHLe9Od Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3458 On Aug 14 06:28, Ken Brown wrote: > 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=3Dalways-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 t= he > >>>>>>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=3Dalways-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 i= s? > >>>>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? >=20 > 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. Given that, we should perhaps skip the memalign override. > >>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? >=20 > Yes. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --Ls2Gy6y7jbHLe9Od Content-Type: application/pgp-signature Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQIcBAEBAgAGBQJSC2GmAAoJEPU2Bp2uRE+gpAsP+QGJ9pcFIwkYEFAC1j2vOClH uutZCS2FuStNcSuXfayG94d7Lv7sLscZUvtS5Xsp40KmCguJX1+QeXsX14GOPzB2 wD5JE7Br3u6JLN1scpjM2Jf4JBulKg3CY3gD1uxXqJmh8Ge1OT4oWO9sSM4FMSmE CSKs1Ci5H90ckYTs9yUSU7Xr4kuvh7Kzs6iZwp7WLJPC3mrDTC7lTbTlDz2vxq4p Lry+Q6wB7fiMZr+DT+7XGdILWV5dIdIhckIUBC0Ux4J6IibU7Pi0RI6GIeS2GznC lwXKIQCYJ5OhHpPKlf8viizDN707qjbmRkWf0YW2W/hwSiN+pkSWZRawRM0Y+6Ku 9axdhlJWEB0ZAxJ/saTEf7X87iqw8OtVpxgjOTZMgaWETzDjE0D8PrYsfemJ8dRF W9pWgefKlT28/09XUIwZsqbDlg+hlprujkXGwP3tNV1Ck3G2dQ2W0NQjop+PJmuT 2Rs98k4Fs1AeGgyNoNQ44aygLySJiDlXaTSoX3SrKgWsAIu36gZXOoMHBqJaVyGv jOHhJJo+yGQuUKYWfqs6RhlPNC3NmTXUxRL3/kGYdNiJDUZMJMDs5PzRBQZXtPgm XspKGaiQggNiR/z+x4EjtrXTfOIvVmB6ayjiDc51jc1GEBkjtIQ+MXwgYTPzofhX +DOK/glZghigp5DavAf1 =d6OL -----END PGP SIGNATURE----- --Ls2Gy6y7jbHLe9Od--