public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-xfree@cygwin.com
Subject: Re: [ANNOUNCEMENT] Uploads for 12 August
Date: Wed, 14 Aug 2013 14:05:00 -0000	[thread overview]
Message-ID: <20130814140518.GK4315@calimero.vinschen.de> (raw)
In-Reply-To: <520B77F0.9010009@cs.utoronto.ca>

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

On Aug 14 08:28, Ryan Johnson wrote:
> 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...


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 --]

  reply	other threads:[~2013-08-14 14:05 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
2013-08-14 14:05                         ` Corinna Vinschen [this message]
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=20130814140518.GK4315@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --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).