From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5002 invoked by alias); 14 Aug 2013 09:17:00 -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 4976 invoked by uid 89); 14 Aug 2013 09:16:59 -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 09:16:58 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 6A2DA520D3A; Wed, 14 Aug 2013 11:16:56 +0200 (CEST) Date: Wed, 14 Aug 2013 09:17:00 -0000 From: Corinna Vinschen To: cygwin-xfree@cygwin.com Subject: Re: [ANNOUNCEMENT] Uploads for 12 August Message-ID: <20130814091656.GE4315@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> <20130814081003.GA29227@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IU5/I01NYhRvwH70" Content-Disposition: inline In-Reply-To: <20130814081003.GA29227@calimero.vinschen.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Found: No X-SW-Source: 2013-08/txt/msg00027.txt.bz2 --IU5/I01NYhRvwH70 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3039 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 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=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 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? > >=20 > > It's memalign, or at least that's what it was in 2007. See > >=20 > > http://cygwin.com/ml/cygwin/2007-02/msg00678.html >=20 > So it's using its own malloc but we don't support overriding other > functions besides malloc/realloc/calloc/free. >=20 > 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. >=20 > I guess we can skip mallopt and mallinfo since they are pretty > seldomly used in user-provided malloc implementations. >=20 > 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 > 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. >=20 > Does that make sense? Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --IU5/I01NYhRvwH70 Content-Type: application/pgp-signature Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iQIcBAEBAgAGBQJSC0sIAAoJEPU2Bp2uRE+gegkP/36+zx/5Pro2mtQchRtBwqlH RApF3J+l7XJBqcSR557T/oaQtrhvWO7zAeQKlZnbLVzwssrCidEVhxOvyEbpM1lg qBHnCxqRD+NoZVnZwcZs7X/4MjLk3ogaejA3lAkdz3FAtBqX6Tcx64nrtxKFOddm a3/43hKiStFeOcW3BTTc51aLRaXd4fg3p+6PnP0OMn6iuJGRhOVfsMR5kvJhexIO HVcArkEEpAOlWZQ8uWXG323WsxS7D+/EobBZ7NkhiitVxS9Uf9ILSJyU5JjV2rMp bThnRKu8SU2/F+bGYEXAwIjI/M4IpeRMZigOJR88LGQrhAouvZCdOsW0m+neOCwb /0V+K2OylzcX0KfwKMmHlZM10iQONW4Md6gWcUI+rjL07qH+YCHW1RKdBQGQySi2 td4w++x0Ps6Tb88B3SCF+BuHy1qoZLsqvvK5nyWWA6CAnLKofGWILBNfQ6xW0Lr3 NU97reNkFBRvGhgbDZAYyOOHtxTE+/zN+zYcyHGmUbC2Nh+QDsBY4VQvoxyJQ2B3 nkg6UflL1SWBl77DiERrc98DoRmvyCk/MMGwq5KjI9mqGRSslWkh7Zj4cEPx8g/L U8CyjdRjkhJaQ++Uh+4zCI1KfQMJ+Jym02ivsXmMSTqh48dQIbnHOwiBGO5ydEqc 9JL9NucurWo7iWED5mGC =iahf -----END PGP SIGNATURE----- --IU5/I01NYhRvwH70--