Hi Holger,
On Mon, Mar 26, 2018 at 8:32 AM, Holger Freyther holger@freyther.de wrote:
On 26. Mar 2018, at 00:00, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Holger,
Hey!
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.
By all means, let's have a smart pointer! It will be beneficial for freetype and many other places. Nobody likes crashing images (for a mistake made in a previous run).
My intent with the CCallOut is inhibit image saving until the code is outside a sequence of (interruptible, hence the backward jump int the example) C calls working with one or more pieces of manually managed memory. But maybe it is best to call it by what it does instead of finding a name of where it is used.
I can't come up with a better example right now. But I think a Smartpointer wouldn't be of much help with a sequence of strtok calls.
word := CStringAPI strtok: cStringPtr safeBytes separator: '\r'. [word isNil] whileFalse: [ word = 'Foo'... word = 'Bla'... word := CStringAPI strtok: nil separator: '\r'------------- Image Save happening right here and word is not nil ----- ].
I hope this is more clear.
Right. So the VM could have a flag that, when set, causes the snapshot primitive to fail, and that flag would be cleared only when all FFI cals had unwound. Would that be enough? What would you have the image do if snapshot fails because FFI calls are in progress?
holger
_,,,^..^,,,_ best, Eliot