Using Grand Central Dispatch (GCD) for preemptive threading

Targets macOS
21

[quote=170628:@Eli Ott]They could, but they don’t have to. And they don’t have to explain why they don’t want to. Take it or leave it.

I assume they will not give any detailed explanation, because it will start a spiral never ending and in the end you’ll be all talking in assembly to each other. Choose the right tool. Go with Objective C or Swift for such a task. Your project is not what Xojo is good at and being developed for.[/quote]

Or he could go plugin, since it is far easier to go Objective-C, then interface with Xojo that way.

[quote=170619:@Christian Schmitz]Thomas, way not ask me to add something to the plugin to do it right without using Xojo for the worked method?
Our plugin can already copy files in background.[/quote]

So is it actually multicore ? If so, this is an extraordinary progress from cooperative threading. If we could have but only one thread that runs on another core, it would a fantastic leap forward, potentially double execution speed.

But is it realistically feasible ? Am I dreaming here ?

22

[quote=170626:@Thomas Tempelmann]I have looked at the assembler code of the functions I wrote, such as myWorker and the helper functions (LockEngage etc.). The code is clearly free of any Xojo runtime code calls (other than the exception handling which I don’t let be invoked by not causing any Xojo exceptions).
[/quote]
This reply is exactly why I didn’t reply with any detail
I expected the “well you’re wrong” response

Basic rules for having this ‘work’:

  • make sure nothing, not even compiler-generated code, calls into the framework or plugins
    something you cant do just by writing Xojo code - you HAVE to examine the compiled exe.
  • make sure all accesses of shared data in Xojo code is wrapped with an OS-level thread lock
    You’d have to restrict yourself to pointers, integers, and structs
    And you’d have to avoid a subset of structure things as well
    CFString, CString, PString, WString are off the table too
    Even literals.
    Basically. You can probably make this work ‘safely’, but you might as well do it in C because the subset of what you CAN use is so small.

So there’s some detail rather than just vague admonishments.

23

If someone has the need to do something in background, maybe contact me to write a plugin function for that.
We do have multithreaded functions for network transfers, file copy, picture effects and much more in MBS Plugins already.

24

BTW, if someone needs to have preemptive multithreading code run in their app, I can be of assistance with that (not for free, though).

I’ve just finished an app that uses a small helper program written in plain C that uses the zlib compression on multiple CPU core to speed up compressing large amounts of data significantly. For all platforms (Mac, Win, Linux), so I have a framework now that works well, based on pthreads with proper locking, using classic producer/consumer and boss/worker techniques.

25

Seems like I might have to approach this also, I’m trying to get a NSDictionary from an API. In most cases it’s lightning fast and unnoticeable, however in some cases it can takes seconds to return the value. During this time the application locks solid.

Even if I create a helper application just for this one API, I then need to serialize and deserialize what could amount to a massive dictionary, which of course would not only slow the entire process down, but would lock the main application as it then reads in the dictionary.

26

BTW, see this thread, where Greg O’Lone suggest practically the same rules for using “thread-safe” Xojo code in pre-emptive threads: https://forum.xojo.com/49704

27

That is NOT what I said. What I was describing was a way to pass information coming from a system callback that is not running on the main thread and then using a timer to retrieve that info. Practically, you can only get away with setting pointers, integers and booleans from the callback.

28

Greg, did you even look at my example code?

Maybe I should have written: What I propose in my sample code is effectively the same as what Greg proposed recently in the linked thread.

The similarities I refer to are:

  • Use pragmas to prevent stack checking and background task
  • Access only globals
  • When accessing Xojo properties, use only non-object types, such as Integer, Boolean, Ptr etc.
  • Poll the data later from “safe” Xojo code, e.g. using a Timer

I also show how to use CoreFoundation functions (which would only work on Mac, though) for adding complex data such as String, and even use an array for that. That supercedes what you suggested.

And all this, what you showed, as well as what I propagate here, is the same, and it contradicts what Norman and Joe stated, which was basically: It can’t ever be safe. Well, actually, later on, Norman admitted that the above rules make it “work”, and that was all that this thread was about: Teaching others how to work with pre-emptive thread callbacks. And we both know that it can work, and we agree on the same rules for that.

Adding to that, I also provided an ever safer solution in the other thread recently (https://forum.xojo.com/49704). It uses the same rules, while adding more safety to it, allowing to access Xojo objects from within the pre-emptive thread.

What irks me about all this is that I keep making suggestions to solve a problem not many but some users struggle with, I provide working examples, even explain how and why it works, which, in my opinion is methodical and scientific, yet no one from Xojo ever acknowledges it and fight me like a plague on it, without ever giving any explanation that counters my arguments. All I ever hear is: Oh no, this can’t work, and we don’t have to explain it, we just know better, trust us on that. Why is that? Is it my attitude? Does what warrant taking me (and all the other interested users) not seriously?