Hi Holger, On Sat, Mar 24, 2018 at 9:09 PM, Holger Freyther <[email protected]> wrote:
> > > > On 24. Mar 2018, at 19:22, Eliot Miranda <[email protected]> > wrote: > > > > Dear Eliot, > > > >> d.) Re-write FreeType with Alien and just use the Plugin to > conveniently link/load to freetype.. > > > > I wonder if there is sense in trying to come up with a general memory > handle object that includes a session identifier, so that attempts to free > stake memory always fail. > > I think it would help with the FT2Handle (to invalidate it on a new > session) but it will not solve other image resume/FFI issues. Let's assume > we have multiple calls into a C library (get a handle, call 1st method, > call 2nd method, have a loop with backwards jumps). Something like: > > > | memory | > memory := GetSomeMemorySomewhere. > > 1 to: 5 do: [ > self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. > ... more C stuff > ]. > > We could be interrupted at any point and when the execution is resumed the > handles might be invalid. In Python terminology something like a context > manager could help: > > > # Image saving is delayed/inhibited until after the callout chain > CCallOut with: [ > 1 to: 5 do: [ > self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. > ... more C stuff > ]. > ] > > What do you think? > Is the intent of CCallOut with: aBlock to collect and defer deallocations until the block completes? I think it's nice but complex and wonder how general it is. But it seems like it would impact a lot of code and require a lot of effort changing existing code bases. My handle scheme is only intended to fix the issue of images crashing on startup. The problems with crashing on startup being a) one loses one's work and b) the issue is hard to debug. That, for me, motivates something like the simple fix I p[roposed. I'm not standing in the way of something more beautiful, but I do believe that one shouldn't make the perfect the enemy of the good. _,,,^..^,,,_ best, Eliot
