unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: reiner.steib@gmx.de, emacs-devel@gnu.org
Subject: Re: All platforms fail with Unicode in menus.
Date: 28 Aug 2004 10:08:58 +0200	[thread overview]
Message-ID: <x5acwfsmzp.fsf@lola.goethe.zz> (raw)
In-Reply-To: <BEEA8234-F8C5-11D8-88A8-000D93505B76@swipnet.se>

"Jan D." <jan.h.d@swipnet.se> writes:

> >
> >> +       inhibit_garbage_collection ();
> >
> >> Can someone that knows ENCODE_UTF_8 and garbage collection well
> >> comment on this patch?
> >
> > I don't know either well, but of course that is not the correct way to
> > fix it.  The correct way would be to add appropriate GCPRO and UNGCPRO
> > calls for temporary data structures that should not yet be collected.
> 
> I suspect this must be done in the coding functions.

Well, I glimpsed through the code, and it looked like there was quite
a bit of work involved.  Basically, whenever you have an automatic
Lisp_Object come into being and its life time reaches across some code
that might CONS memory (almost any Lisp code), and it may be the only
pointer to the respective Lisp Object, then you need to GCPRO it.

Glancing through the code looked like there was quite a bit of that.

The results of things like ENCODE_STRING or what it was need to get
into something GCPRO before garbage collection can strike.

> This call to inhibit_garbage_collection was there about two years
> ago (1.234 removed it), and it is still present in macmenu.c, which
> is the only reason the mac port works better.  I suspect the w32
> port also has this problem, but I can't test that port.  I'll work a
> bit more on this, as a temporary solution I checked in this patch.

Yes, as a temporary solution it will work, but it has the disadvantage
that during menu buildup, no old memory will be reclaimed for the
construction of the menus.  And I don't even know how long the effects
of inhibit_garbage_collection will last.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2004-08-28  8:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-25 21:48 All platforms fail with Unicode in menus David Kastrup
2004-08-26  8:13 ` YAMAMOTO Mitsuharu
2004-08-26 18:30 ` Jan D.
2004-08-28  7:11   ` David Kastrup
2004-08-28  7:42     ` Jan D.
2004-08-28  8:08       ` David Kastrup [this message]
2004-08-28  8:24         ` Andreas Schwab
2004-08-28 21:38     ` Stefan
2004-08-28 22:18       ` Jan D.
2004-08-28 22:38         ` Stefan
2004-08-30  7:52   ` YAMAMOTO Mitsuharu
2004-08-30 10:28     ` Jan D.

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x5acwfsmzp.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=reiner.steib@gmx.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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