Re: [ANNOUNCEMENT] Uploads for 12 August

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

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=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.

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?
> 
> Yes.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]