Re: [eclipse-clp-users] BAD_TERMs in the C/C++ interface

From: Joachim Schimpf <jschimpf_at_...311...>
Date: Sat, 14 Dec 2019 01:21:33 +0000
Hello Victor,

On 13/12/2019 18:46, Victor Mataré wrote:
> I'm making extensive use of the C++ interface, and the aggressive garbage
> collection in eclipse-clp is still giving me trouble. So as I understand it,
> any term goes BAD after it's been given to the eclipse engine once.
> 
> Now I already have infrastructure in place to deal with that, but in my
> control flow it's becoming a huge issue that I never really know whether a
> term has gone BAD or not. Is there any way to query whether a certain term
> (handle) has already been garbage collected?

I'm quite confident that the C++ interface has the functionality to solve your 
problem in a clean way, no strange workarounds should be necessary.

 From what you say, I suspect that you may not be using term references where 
they are needed.

To give some background: "terms" are always stored and managed by an ECLiPSe 
engine.  When an engine runs, it may (a) attempt to garbage-collect terms, and 
(b) move terms as a side effect of garbage collection.  For that reason, the 
engine must know about any references to terms that you are keeping in your own 
C++ data structures.

The way to do that is to use the EC_ref/EC_refs class: terms assigned to an 
EC_ref/EC_refs will not be garbage collected, and the references will be 
correctly relocated when the term is moved in memory.  In contrast, the EC_word 
class must be considered volatile: the content of an EC_word becomes invalid 
once you pass control to the engine (the reason EC_words exist at all is that 
they have less overhead, and are good enough to hold subterms temporarily while 
constructing or deconstructing complex terms).


That's my best guess without knowing your code.  It would also be helpful to 
know whether you observe this problem already in ECLiPSe 6.1, or whether it is 
new in 7.0.

Cheers,
Joachim
Received on Sat Dec 14 2019 - 01:37:01 CET

This archive was generated by hypermail 2.3.0 : Tue Apr 16 2024 - 09:13:20 CEST