This is the mail archive of the cygwin-xfree mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] Uploads for 12 August


On 8/14/2013 8:14 AM, Ken Brown wrote:
On 8/14/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.

Thanks.  It should only be emacs that needs rebuilding; glib doesn't
supply its own malloc, but emacs does.  I'll test it and report back.

Success! Thanks very much for the quick fix. I've got new emacs packages ready to go for both 32-bit and 64-bit. Do you expect to release cygwin-1.7.24 soon? If not, I'll upload the new packages as test releases for anyone who wants to install the snapshot.

Ken

P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need to patch gmalloc.c upstream before the fix will take effect.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]