I started that thread!!!
In any case the lack of adding things that help give us more power in a approachable manor with less work, is why I said in the wishlist thread I have not been excited about new Xojo features for years (for me desktop is of primary interest) …
This area certainly could have been one such thing … AND would have been applicable to every type of platform as even mobile is multi core these days…
But such new features that make sophisticated techniques/capabilities more approachable are the type of features that got me excited, as they enable me to do things quickly that usually would only be done by very experienced full time developers… That type of vision is what it seems Xojo inc has lost now that I think about it now that focus is more platforms and more strictness.
Back in 2008, after he had left REALSoftware, Mars Saxman had a blog post where he talked about how he would have wanted to approach this if he had stayed. He described what I had in mind but he had the vocabulary/knowldge to express it much better than I could, when I had the discussion with Norman (who seemed to miss the essence of what I was saying) many years ago.
It is a (very) high level description about how to create a general purpose framework to support helper apps… Outside of integrating it into the IDE in single project, it points out how we could create some general classes to help with this (of course it would not as simple or elegant an API if Xojo inc did it with under the hood support).
I still think when they were rewriting the IDE (never mind creating the new framework at the same time) they missed a HUGE important opportunity to deal with multiple cores that would have payed many long term dividends.
Mars wrote:
[quote]I had a plan for multiprocessor support in REALbasic. If I had stayed on with REAL Software, my solution would not have been to add a PreemptiveThread class in parallel to the existing Thread class, but to implement something completely different. A new project-item type, which we might call Subprocess, would have allowed you to effectively embed a little console app into your larger project. Creating and invoking a new instance of this class would spawn off a subprocess, which the OS kernel would then schedule on any available processor.
The limitation, of course, is that this would genuinely be a separate process. It could use the same classes as the host app, but none of the same object instances, and none of the same static/shared variables. Instead, youd send data back and forth, as though on a socket: each subprocess would be automatically wired up with a pipe-style communications channel back to the host app. Some basic serialization primitives would let you send the contents of arrays, dictionaries, and structures back and forth, triggering an event in the receiver. This, I think, would have directed people straight toward the best solution for multiprocessing, instead of giving them primitive, low-level tools theyd have to use to build their way up from scratch.
[/quote]
Bold emphasis is mine…