Another problem with continuations is that they can induce memory leaks with our current memory management policy: think about longjmping out a texmacs function which has few smart pointers to some texmacs objects: these objects correcly take into account the pointers in their reference count, but when the function is exited via a continuation then I'm not sure (more: I'm quite sure of the opposite) whether the destructors of the smart pointers are called and as a consequence the reference counts are incorrect. If this is true we cannot allow continuation since they interact unpredictably with the C++ code.
I think that the bug I'm referring to is quite serious and I would like to get rid of it as soon as possible. I do not know why such kind of problems do not show up also in the X11 code. max On 22 déc. 2010, at 16:17, Joris van der Hoeven wrote: > Dear Max, > > Yes, I am aware of the fact that our support for continuations is fragile. > By the way, the copy-stack-based implementation in Guile is quite inefficient. > They will induce another problem if we ever want to replace Guile by > another Scheme dialogue with potentially different conventions or > no support of continuations. I have the plan of completely removing > our dependency on continuations and simply use closures instead. > But this will take some time, of course. What should be easier and > also beneficial would be to replace the existing code for interactive > footer commands by a closure-based implementation. If you have some time, > then you may try. Otherwise, I will do it, when I will have time... > > Best, --Joris > > > Unrelated P.S.: one of the last annoying remaining bugs in the Qt version > is the often erroneous behaviour of images. If someone has some time to > take a careful look at this problem; cf. an earlier post on > this list to Norbert. > > > On Wed, Dec 22, 2010 at 04:00:39PM +0100, Gubinelli Massimiliano wrote: >> Dear Joris, >> I just realized that the allowing the scheme code to use continuations puts >> some restrictions on the coding style in the C++ side. Each time we call a >> scheme closure we are not sure to come back (maybe the closure invoke a >> continuation and we jump in a another stack status and in a different point >> of the program). Thus if we are modifiyng internal structures of the program >> we must be sure that they are in the correct state at each of these "cut" >> points. I didn't realized this before. I wonder if you take care of this in >> the texmacs code when you invoke scheme command (essentially in interactive >> input stuff). I like very much the idea of having continuations availables >> in the scheme part. On the other side I have a very nasty bug which is >> probably generated by the bad interaction of the continuation jumps with the >> state of Qt/Cocoa internal structures. The bug does not happen in Linux or >> Windows. I do not know if it happens with Carbon. I still do not have found >> a way to circumvent it by modifying the Qt plugin code. >> I'm trying to fix parts of my code where I didn't take into account the >> possibility of longjmps generated by scheme continuations. But I do not >> think this particular bug is due to a problem in my code. Seems more an >> incompatibility of the Qt framework with this programming style. I have to >> investigate further. >> >> >> The bug I'm referring to is the following: open a new buffer and another >> one, modify the second and try to close it. After confirming at the footer >> prompt you get a EXC_BAD_ACCESS exception in the Qt/Cocoa internals. >> >> best >> max >> >> ps: I post to the list to allow other people partecipate to the discussion >> if the want. >> >> >> >> >> >> _______________________________________________ >> Texmacs-dev mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/texmacs-dev > > _______________________________________________ > Texmacs-dev mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/texmacs-dev _______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
