6:47 p.m.
As usual when I try to do anything, I find I really don't quite
understand GC and when GCPRO is necessary.
Can somebody help me with a particular example?
concat() in fns.c GCPROs its arguments, to be helpful to the caller.
What is it that concat() does that could cause a GC or QUIT?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:16 a.m.
Julian Bradfield writes:
As usual when I try to do anything, I find I really don't quite
understand GC and when GCPRO is necessary.
You need to know what functions can GC. Sometimes this is documented,
sometimes not. :-(
Can somebody help me with a particular example?
concat() in fns.c GCPROs its arguments, to be helpful to the caller.
What is it that concat() does that could cause a GC or QUIT?
It calls wrong_type_argument, which calls Fsignal, which is documented
to GC.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:25 a.m.
Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
As usual when I try to do anything, I find I really don't quite
understand GC and when GCPRO is necessary.
Did you look at the section on garbage collection in the internals
manual? In particular, there's a subsection on GCPRO.
concat() in fns.c GCPROs its arguments, to be helpful to the caller.
What is it that concat() does that could cause a GC or QUIT?
It allocates. If there's not enough free space in the heap to satisfy
an allocation, a GC is triggered.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:32 a.m.
Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
> As usual when I try to do anything, I find I really don't quite
> understand GC and when GCPRO is necessary.
Did you look at the section on garbage collection in the internals
manual? In particular, there's a subsection on GCPRO.
Yes...but I should have read the Invocation section more carefully.
> concat() in fns.c GCPROs its arguments, to be helpful to the
caller.
> What is it that concat() does that could cause a GC or QUIT?
It allocates. If there's not enough free space in the heap to satisfy
an allocation, a GC is triggered.
The manual clearly says "this is _not_ the case".
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:14 a.m.
Ar an triú lá de mí Feabhra, scríobh Julian Bradfield:
>Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
>> As usual when I try to do anything, I find I really don't quite
>> understand GC and when GCPRO is necessary.
I felt like this for years, and now I don’t any more, mainly because I
committed a few patches where things got garbage-collected that shouldn’t
have been, and it wasn’t always my mistake. Cf. this and the related thread:
http://mid.gmane.org/19139.32892.491325.763382＠parhasard.net
The #'reduce bug here *was* my mistake, though:
http://hg.debian.org/hg/xemacs/xemacs/rev/4c4085177ca5
It’s difficult to get GCPRO right all the time, but understanding when one
should GCPRO is not that difficult.
>Did you look at the section on garbage collection in the
internals
>manual? In particular, there's a subsection on GCPRO.
Yes...but I should have read the Invocation section more carefully.
>> concat() in fns.c GCPROs its arguments, to be helpful to the caller.
>> What is it that concat() does that could cause a GC or QUIT?
>
>It allocates. If there's not enough free space in the heap to satisfy
>an allocation, a GC is triggered.
The manual clearly says "this is _not_ the case".
Right. Feval(), Ffuncall() are what to worry about. The CHECK_STRING() etc.
macros are less of an issue now, they used to signal continuable errors, but
now they’re non-continuable, so you won’t get past that line of the C code
with some memory you’ve just allocated having disappeared. But the various
code that calls wrong_type_argument () in emulation of the continuable
behaviour will shoot you in the foot.
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:28 a.m.
Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
>It allocates. If there's not enough free space in the heap to
satisfy
>an allocation, a GC is triggered.
The manual clearly says "this is _not_ the case".
What is not the case?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:43 a.m.
Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
>>It allocates. If there's not enough free space in the heap to satisfy
>>an allocation, a GC is triggered.
> The manual clearly says "this is _not_ the case".
What is not the case?
That allocation can trigger a GC - in the sense of running a GC
immediately.
Allocation as such does not cause a GC within the code of concat(),
though it may cause the reserve to drop such that GC happens next time
GC is possible.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:12 p.m.
Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
>Julian Bradfield <jcb+xeb(a)jcbradfield.org> writes:
>>>It allocates. If there's not enough free space in the heap to satisfy
>>>an allocation, a GC is triggered.
>> The manual clearly says "this is _not_ the case".
>What is not the case?
That allocation can trigger a GC - in the sense of running a GC
immediately.
Allocation as such does not cause a GC within the code of concat(),
though it may cause the reserve to drop such that GC happens next time
GC is possible.
Sorry, I was very unclear in my choice of words:
The allocation may eventually lead to a GC happening. A superficial
look over concat indeed revealed no possibilities for QUIT or explicit
GC, but I'm assuming the author was trying to be safe rather than sorry.
GCPROs are much easier to add while writing the code, as opposed to
putting them in afterwards, so I'd say the choice was prudent.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:38 a.m.
Michael Sperber writes:
The allocation may eventually lead to a GC happening. A superficial
look over concat indeed revealed no possibilities for QUIT or explicit
GC, but I'm assuming the author was trying to be safe rather than sorry.
No, there's an implicit call via wrong_type_argument to Fsignal, which
can GC.
I'm not sure why concat should call w_t_a, though. That would seem
safe only in the context of a user command.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5387
days inactive
5389
days old
8 comments
4 participants
participants (4)
-
Aidan Kehoe -
Julian Bradfield -
Michael Sperber -
Stephen J. Turnbull