Obj-C Blocks as Callbacks

I haven’t tried it, but it sounds like that should work.

Just want to say, thanks @Joe Ranieri , I just added your plugin to a project and it works really really well! Thanks for sharing and helping out.

Is there an update for cBlocks and 64 bit ?

reloaded the cBlock dropbox link. Joe has updated it to 64 bit.
Thanks man.

https://xojo.io/f0e2dc7227f3

I need a .rbx version of the Blocks plugin for use with REAL Studio. Is that available? There’s no source code of the plugin, is there?

Mercy.
Unfortunately, the IDE (2012r2.1) says it’s not compatible (i.e. the plugin uses a newer SDK than the IDE supports).

The MBS Blocks class should work for Real Studio:
http://www.monkeybreadsoftware.net/class-blockmbs.shtml

Yes, the BlockMBS works.

Well … the MBS block plugin has one issue currently, though: If the block callback takes place in another thread, the callback into Xojo can only take place after the plugin code first switching to the main thread. Now, if the callback was passed an ObjC object, such as NSError, that could get autoreleased BEFORE Xojo gets a look at it. This is happening, for instance, with the NSUserScriptTask. I will have a look now whether Joe’s plugin handles this better.

Turns out Joe’s block plugin is even worse because it does not even transfer to a safe thread but makes the call from the pre-emptive thread into Xojo code, crashing the Xojo runtime randomly. An Open source project or even some docs warning about this would be appreciated here.

I’ll change my class later.

I’ve now also managed to use Blocks callbacks in plain Xojo code. It’s a bit tricky, especially when getting callbacks from pre-emptive threads, but it’s doable (same risks apply as with my previously discussed GCD thread demo, see here)

Like as joe said

Well, if Joe would fix his own plugin to work with pre-emptive callbacks, that’d be great, too. Until then, I keep making sure that my code works with every new release. Fortunately, compiled code doesn’t suddenly change, nor do the Xojo libs I’ve build into my app, so I’m fine with it. If it stops working, I’ll find a new solution, maybe we’ll even have a built-in Xojo functionality for blocks by then instead of being forced to find work-arounds for missing essential features in Xojo.

BTW, why do you keep telling me that it’s unsupported? I’ve never asked for support on this (well, years ago I had begged to make certain low level functions thread-safe, which was ignored). All I have done here is ask if someone can come up with proof that it won’t work, and no one has. That was even before I had figured it out myself. I don’t need support, I’ve learned long ago I can’t rely on that :slight_smile:

You cant pick one or two functions and make them thread safe without auditing everything they rely on to also make sure that is thread safe.

I remind you its unsupported because its unsupported & I dont want someone to stumble on the thread later and assume that “well since thomas said …” that is IS supported in any way shape or form.

Trust me - if / when we have an answer as to how we intend to deal with multi-core multi-cpu issues everyone will know

Priorities are what they are

This would require copying all of the arguments from the stack/registers, retaining all of the reference counted arguments, punting things over to the main thread, and then copy everything back to the stack/registers with the hope that it’s all still valid. It’s probably doable if enough metadata about the delegate was present at runtime (it isn’t).

I have seen firsthand projects relying on unsupported behavior like this and not knowing about it because it came from a forum post, email, or third party. This is why we try to speak up any time unsupported things are being discussed (regardless of the users involved).

Or you could simply use the sync version of the dispatch call. That way, the thread that holds the temp refs will not release any objects prematurely. That’s what I’m doing in my code, and it works fine.

Your plugin could offer either a boolean “sync” property or parameter for this, or it might even detect the need automagically by checking if the callback is on the same thread as the invoker - if same, use dispatch_async, otherwise use dispatch_sync.

Fair enough.