Re: [Texmacs-dev] continuations

[Gubinelli Massimiliano]

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
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/texmacs-dev
> 
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/texmacs-dev