I was assuming that too, but that presumes you can call things which are not inline. And then you’d also want to keep a static boolean to know when you had already made the call to register the plugin license etc.
Why couldn’t the compiler just figure that out? Include everything, then let the optimizing compiler strip out stuff not referenced?
[quote=480928:@Kem Tekinay]Q&A just wrapped up. Just to be clear, in v.1 the Worker won’t have access to anything in the main project, including your classes, modules, or methods. That will have to be included in the ProcessJob (or whatever it was called) event.
At least, for now.[/quote]
Q & A made it seem like Worker was not in 2020r1 at all
[quote=480939:@Douglas Handy
Incidentally, thanks for the shared memory classes and it seems to me they will likely be a way to “share” data with a Worker. In the Q&A when I asked about Workers and shared memory, the question really asked if there was any reason shared memory such as your classes would not work. Not asking if Xojo would have inherent built-in support for shared memory.[/quote]
Just be aware that shared memory based on the system v shared memoty cant work in macOS app store sandboxed apps
Sam posted about this this morning
https://forum.xojo.com/51306-shared-memory-app-sandbox
That is likely a safe assumption, as I believe it is probably the “Multicore” reference in priority 5 of the roadmap
Worker will not be in 2020r1 as I write this.
[quote=480928:@Kem Tekinay]Q&A just wrapped up. Just to be clear, in v.1 the Worker won’t have access to anything in the main project, including your classes, modules, or methods. That will have to be included in the ProcessJob (or whatever it was called) event.
At least, for now.[/quote]
Well hopefully not for long…
But will have all the code (methods) you put on the workers subclass available as long as it is self contained (does not depend on code elsewhere in the project) ?
If not, that is AWFULLY limiting.
-Karen
Unclear, or perhaps undetermined, right now.
would have guessed that any console safe code would be sent to the worker to be compiled and that could include classes / modules etc that are in that same project
if thats not the case then this really is limiting as we cant even send data to the worker that could create an instance of one of our classes from that data in that worker and then use the normal methods weve defined on it to manipulate things
bummer
Workers are console projects.
And if I remember correctly what Geoff said, the IDE creates a console project in the background with the code.
So I would assume we need to tell the compiler which classes to include and not just include everything.
Today we have Memoryblocks, maybe a SharedMemoryBlock with synchronization methods is one way to go.
Property m As SharedMemoryBlock[code]
m = New SharedMemoryBlock(10000)
m.Lock() // Wait until you can lock it for exclusive access
m.Tag = “step1” // any interprocess tip
m.Int32Value(100) = 1111
m.Int32Value(123) = 12345
m.Unlock()
Do Until m.GetLock() // True if you got the lock
CheckAnotherThing
Loop
// Got the Exclusive access again
m.Tag = “step2” // a interprocess tip if necessary
m.Int32Value(111) = 33333
m.Int32Value(222) = 44444
DoSomethingWith(m)
m.Unlock()
Do
If m.Tag = “done” Then Exit // Another worker changed it
Loop
m = Nil // free the memory[/code]
[quote=480968:@Christian Schmitz]the IDE creates a console project in the background with the code.
So I would assume we need to tell the compiler which classes to include and not just include everything.[/quote]
A smart compiler can infer what’s needed looking to what the worker “touches” and backpropagating to what the “touched” things touch too.
Well, there is mutex class to sync already and shared memory class in MBS Plugins.
But most likely most people won’t need it.
e.g. you send job to process file, so your string may just be a JSON with file paths.
Most of the the time I need things like Sam. Something loaded and fast touched by many threads. Having such contents moving around by files or IPCs is a dumb way of doing it. Imagine someone being operated by 3 surgeons in different parts of the body, this the model of 3 workers with a shared body, now let’s be dumb and make 3 surgical rooms with one surgeon each and moving the body to each room when one of them need to do its part… The entire surgery will take ages.
[quote=480968:@Christian Schmitz]Workers are console projects.
And if I remember correctly what Geoff said, the IDE creates a console project in the background with the code.
So I would assume we need to tell the compiler which classes to include and not just include everything.[/quote]
Of course
a compat flag would be nice to indicate that 
what API are they based on
If its the low level System V apis then you cant use them in sandboxed apps
Sam posted about this this morning
They might need to be the XPC shared memory ones on macOS
I gave up after 5 minutes (and when I finished to drink my glass of Pepsi).
Can workers used in an application with Gatekeeper in macOS and AppStore?
In theory yes, and I hope that Xojo are testing their solution with Sandboxed applications.
[quote=480928:@Kem Tekinay]Q&A just wrapped up. Just to be clear, in v.1 the Worker won’t have access to anything in the main project, including your classes, modules, or methods. That will have to be included in the ProcessJob (or whatever it was called) event.
At least, for now.[/quote]
I’ll admit I wasn’t expecting to read this. Do you know what the reasoning is behind it? Let’s hope that this changes before release.