On Samstag, 14. Dezember 2019 02:21:33 CET Joachim Schimpf wrote: > 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. It's not that. I don't need persistent term references because I'm not pulling information out of the eclipse engine. In the part I'm talking about, I'm basically just using compile_term/1 to "compile" a C++ object structure into a bunch of prolog clauses. The problem is that some of those C++ objects represent variables that are referenced in other objects (i.e. they are not singleton variables). So I can't simply re-initialize the variable terms whenever they're referenced because that would make them singletons. I've now resorted to initializing these variable terms once before building a term or clause that has variables, but that is error prone because I didn't expect to have that problem when I designed the control flow. Now that I think of it, some clearer documentation might have helped me in the beginning. There is just this rather vague half-sentence in the Embedding and Interfacing Manual: "terms do not survive the execution of ECLiPSe" None of these words are really clear. What terms are really affected and how, what does "survive" mean and what does "execution" mean? I think the Embedding Manual should have at least a short section about memory management that clearly states what happens. In fact, it should have a big fat warning along these lines: ============================================================================== Every EC_word that has been put into post_goal() is invalid after EC_resume(). That includes all pieces of complex terms. Putting an invalid EC_word into another post_goal() leads to undefined behaviour, which might cause the eclipse engine to corrupt data, crash immediately, crash randomly, or to never crash. ============================================================================== At least that is the behaviour I observed so far when I made mistakes with this. I assume that the undefined behaviour helps performance, but what would also be really useful for debugging these things is a switch that makes it crash immediately. Sure, I can design my client application so that it cannot happen, but I failed to do that initially because there was neither a fat warning nor a fail-fast behavior. It's really a huge pitfall if you're designing a larger application. Hope I did get the problem across ;-) Best regards & thanks for your helpful support, Victor PS: If you look at e.g. SWI Prolog, they expose a GC frame object which makes their (also non-trivial) memory management explicit, controllable and therefore obvious. Lacking that, I believe one does need very clear documentation.Received on Sun Dec 15 2019 - 04:14:50 CET
This archive was generated by hypermail 2.3.0 : Wed Sep 25 2024 - 15:13:21 CEST