public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
To: cygwin-xfree@cygwin.com
Subject: Re: [ANNOUNCEMENT] Uploads for 12 August
Date: Wed, 14 Aug 2013 12:28:00 -0000 [thread overview]
Message-ID: <520B77F0.9010009@cs.utoronto.ca> (raw)
In-Reply-To: <20130814115920.GH4315@calimero.vinschen.de>
On 14/08/2013 7:59 AM, Corinna Vinschen wrote:
> On Aug 14 13:33, Corinna Vinschen wrote:
>> On Aug 14 12:53, Corinna Vinschen wrote:
>>> 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:
>>>>>>>> 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.
>> On second (third? fourth?) thought, I think we should do this with
>> posix_memalign only. valloc is just as obsolete as posix_memalign.
> I applied the patch to allow overriding posix_memalloc only, and I'm
> building snapshots right now. For testing, this requires to rebuild
> either emacs, or glib, or both, I'm not sure. Make sure to link against
> the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing.
Wait, it's "memalign" that's obsolete and "posix_memalign" that you
added a patch for, right? The last couple of paragraphs were a little
confusing...
Ryan
--
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/
next prev parent reply other threads:[~2013-08-14 12:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <520A01DF.1040208@alice.it>
2013-08-13 12:08 ` Angelo Graziosi
2013-08-13 14:13 ` Ken Brown
2013-08-13 14:30 ` Ken Brown
2013-08-13 18:09 ` Yaakov (Cygwin/X)
2013-08-13 18:26 ` Corinna Vinschen
2013-08-13 22:00 ` Ken Brown
2013-08-14 8:10 ` Corinna Vinschen
2013-08-14 9:17 ` Corinna Vinschen
2013-08-14 10:28 ` Ken Brown
2013-08-14 10:53 ` Corinna Vinschen
2013-08-14 11:34 ` Corinna Vinschen
2013-08-14 11:59 ` Corinna Vinschen
2013-08-14 12:14 ` Ken Brown
2013-08-14 15:55 ` Ken Brown
2013-08-14 19:00 ` Corinna Vinschen
2013-08-14 12:28 ` Ryan Johnson [this message]
2013-08-14 14:05 ` Corinna Vinschen
2013-08-14 14:55 ` Corinna Vinschen
2013-08-13 19:26 ` Charles Wilson
2013-08-13 14:46 ` Angelo Graziosi
2013-08-14 19:59 ` Angelo Graziosi
2013-08-12 19:38 Yaakov (Cygwin/X)
2013-08-24 0:30 ` Enrico Forestieri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520B77F0.9010009@cs.utoronto.ca \
--to=ryan.johnson@cs.utoronto.ca \
--cc=cygwin-xfree@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).