Does anyone know of a plugin that will allow threading that doesn’t lock up the thread when doing simple things like moving windows or opening menus?
Do I really need to farm out my threads contents to a console app and talk to it via IPC?
- this is not really possible unless the plugin does the work. See the MT methods in MBS Plugin.
- yes
I still think making some key areas thread safe in the framework would help a lot.
Like locking objects/strings, object allocate/destroy.
we had a MBS thread plugin, too.
But you were not be able to do much there.
Well also remember Christian even your own plugin methods, that you think are threadsafe…Xojo creates wrapper around them and that wrapper function does yield, and all that. (I was bitten badly by that earlier this year and it took me a while to realize that RealLoadClassMethod was not giving me pointer to my own method but actually pointer to the wrapper around my own method.
Thanks guys.
When I have need for preemptive threads, I write them in C and build a (dynamic) library from it, using Xcode or Visual Studio Express. Then I can use it from Xojo with a few declares. You’ll need to write all the threaded code in C, though. Can’t be done in Xojo unless you only work with Memoryblocks, structs, integer and doubles. No objects, no Strings, no Arrays. I had posted an example (for OSX) a year or two ago where I demonstrate this, but it’s very limited. It may be easier to learn doing it in C.
Also, MBS plugins offers - at least for OSX - a “CarbonTimer” (IIRC) that will fire even during open menus and drags.
The helper/IPC isn’t that a bad a solution; I built a framework last year and am currently using it in HDRtist NX. I intend to release the source code later this year.
Basically; when the helper is launched its passed a random IPC socket path.
The main app then serialises the method to execute and the properties required for that method.
The helper deserialises the data back into Xojo properties and then processes them.
The helper can return a keyed value at any time bavk to the main application.
The main application can also send a keyed value to the helper at any time the helper is running.
Once the helper has finished its task it auto quits.
I setup a copy files step to copy the compiled helper into the main apps ‘macOS’ folder.
Debugging the process was actually easier than I thought and I really appreciated being able to use a shared module between the helper and main app.
My biggest problem with this method is the duplication of shared libraries, adds bulk to your application. Would be nice if there was a way to use the same libraries between the main app and the helper.
I’d love to see a ‘helper’ class; which looks and smells like a ‘thread’ but is actually a helper application.
Huh? That makes no sense to me. The point of shared libs is that they are shared, i.e. avoid duplication.
[quote=317122:@Sam Rowlands]The helper/IPC isn’t that a bad a solution; I built a framework last year and am currently using it in HDRtist NX. I intend to release the source code later this year.
Basically; when the helper is launched its passed a random IPC socket path.
The main app then serialises the method to execute and the properties required for that method.
The helper deserialises the data back into Xojo properties and then processes them.
The helper can return a keyed value at any time bavk to the main application.
The main application can also send a keyed value to the helper at any time the helper is running.
Once the helper has finished its task it auto quits.
I setup a copy files step to copy the compiled helper into the main apps ‘macOS’ folder.
Debugging the process was actually easier than I thought and I really appreciated being able to use a shared module between the helper and main app.
My biggest problem with this method is the duplication of shared libraries, adds bulk to your application. Would be nice if there was a way to use the same libraries between the main app and the helper.[/quote]
Hi Sam
We have just done something similar but used sockets instead of IPC. We used sockets because we wanted our workers to be able to run across multiple computers and not just the same computer as the controller app (our workers stay running rather than quitting after finishing a task).
I would still like the ability to run code in a pre-emptive thread though. It is disappointing that RB / Xojo has never provided us with anything more than co-operative threading.
I think Sam means the bloat from having the same shared libraries in his helper app as well as his main app. Having the ICU lib forced on us doesn’t really help (-:
Well…
In the early days, RB did indeed have support for pre-emptive threads, but I guess the devs ran into too many difficult-to-debug problems due to not having locked resources properly in some places, that they eventually gave up and just played it safe.
I still don’t follow. Do you mean that two separate apps each have copies of the same shared lib? Well, that could be avoided if one app is inside the other, and both refer to the SAME lib on disk. That’s what shared libs are for. Or maybe you all confuse terms and mean not shared libs but hard-linked libs (those get linked to the main app’s executable file, and you end up with duplicate libs in many files that way)?
[quote=317181:@Thomas Tempelmann]Well…
In the early days, RB did indeed have support for pre-emptive threads, but I guess the devs ran into too many difficult-to-debug problems due to not having locked resources properly in some places, that they eventually gave up and just played it safe.
I still don’t follow. Do you mean that two separate apps each have copies of the same shared lib? Well, that could be avoided if one app is inside the other, and both refer to the SAME lib on disk. That’s what shared libs are for. Or maybe you all confuse terms and mean not shared libs but hard-linked libs (those get linked to the main app’s executable file, and you end up with duplicate libs in many files that way)?[/quote]
That must have been a long time ago (+ 10 years). Playing safe was probably fine in those days when CPUs were getting faster and faster but in these multi-core times it seems quite lame that there is no support at all.
I’m sure Sam means the Xojo dylibs. He has two apps so he has two copies of them.
Correct.
For the main application, there’s the dylibs in the Frameworks folder, then each helper has it’s own “Libs” folder. I tried using symbolic links to redirect and reduce bulk, but that lead to crashes.
At some point Xojo is probably going to have to address the threading situation; some of the macOS API returns values on threads that Xojo can’t access. I suspect that as time goes by more and more Apple API will multi-threading.
What’s a couple of MBs?
I’ve been experimenting with this, too, because getting data out of Mail is very slow. Unfortunately, sending large amounts of data from helper app to main app made the code even slower than before.
[quote=317297:@Beatrix Willius]What’s a couple of MBs?
I’ve been experimenting with this, too, because getting data out of Mail is very slow. Unfortunately, sending large amounts of data from helper app to main app made the code even slower than before.[/quote]
If only it was a couple of MBs. We have 5 Xojo console apps as part of our server install. I’m pretty sure that is over 100MB of stuff which we could do without (I’m looking at you ICU lib). Unfortunately, we cannot share the libs as the apps are not in the same location.
It can also potentially effect startup times if you are deploying on services such as AWS Lambda.
re> you attempts with helper apps. If you have the MBS plugins you might be able to use the shared memory functions to optimise the passing of data between apps.
@Kevin Gale: 100 MB per helper app is bad.
Thanks for the tip with the shared memory functions. Looks interesting. The examples don’t really show much so I’ll need to do some testing.
[quote=317303:@Beatrix Willius]@Kevin Gale: 100 MB per helper app is bad.
Thanks for the tip with the shared memory functions. Looks interesting. The examples don’t really show much so I’ll need to do some testing.[/quote]
Its actually 20+MB per app which results in >100MB in total.
I think you basically treat the FileMapingViewMBS as a memory block that you can share between apps. I’m sure there is a basic client/server example on the MBS site.
What if the helper’s Unix executable is in /Contents/MacOS ? Then the directory structure would be just the same. I can’t recall if this is OK with Apple, though.
In Windows, it is possible since both exe can reside in the same folder.