Re: [ANNOUNCEMENT] Uploads for 12 August

[Ken Brown <kbrown@cornell.edu>]

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/