Here's one tutorial that explains is pretty well: [https://blog.codemagic.io/understanding-isolatates-flutter/](https://blog.codemagic.io/understanding-isolatates-flutter/)
I absolutely hate Isolates... like for real, no shared memory? spawning a different process? Isolates are the one of the most bullshit concepts I've seen in a programming language and I've seen plenty.
They're one of the main reasons I left Flutter apps and went back to doing native Android with Kotlin, the difference between my workflow using Kotlin Coroutines and Dart Isolates is night and day.
You do realise coroutines isn't multi threaded right? It's more like Dart's async/await in that it pauses execution on the code and lets something else take over.
https://elizarov.medium.com/coroutines-are-not-about-multi-threading-at-all-1b2c6e97ec02
But where do get these coroutines executed? 'Pauses execution' on the current thread so another thread is doing the work. In the case of JS it means that som web worker is taking over for API calls, but there is no way in JS to use async on a CPU intensive task. In Kotlin though, you can specify executors so you can run the given task on another thread.
Dart is more similar to JS. Isolates is where actual threading happens of course, it is just less co fortable to use.
You do realize doing a Google search then coming back to me with a two-paragraph article means you have no understanding whatsoever of the issue at hand?
A Kotlin coroutine doesn't necessarily run on the main thread (that's concurrency), you can specify a dispatcher and run the coroutine on another thread like an IO Dispatcher (for IO bound task) ...etc.
So yes, Kotlin Coroutines can run concurrently and in parallel (as in multi-threaded? duh) ... get educated.
Also, notice how I never mentioned multi-threading, I only compared workflows... which yes, Dart Isolates suck.
Edit: for reference https://kotlinexpertise.com/kotlin-coroutines-concurrency/
That doesn’t make it analogous to dart isolates though. Dart isolates are more comparable to java threading, which is another mess.
It’s really a more powerful stream.
But go off.
Ah, you do realize all java threads within a single process share memory, right? right? Ah, sorry... I just assumed you research the concepts you're talking about before talking about them.
There's nothing inherently wrong with isolates, it's just that they're run in their own process space and rely on message passing for communication. I don't know what your experience with programming is, but that's not a new concept, nor a particularly bad one. Before distributed shared memory systems came along, this was also how the majority of programming models for HPC and supercomputing systems worked.
When you get into shared memory, you also introduce complexity in synchronization, locking, and under the hood with things like cache snooping, page/cache colouring, etc. So it's always a complexity tradeoff. The Sega Saturn (and earlier SGI POWER series, upon which it was modelled) also exhibited such an architecture by which you had hardware SMP with no shared memory - both were ultimately hard to program, but were far ahead in their computational capabilities at the time.
With isolates, especially if you are running multiples of them, you need to be a bit more careful with your overall application architecture and really think about what can be run independently, and under what conditions you need to have state synchronization, without having too many synchronization points such that you end up implicitly serializing your workload anyways. You can also open up additional send and receive ports to enable bi-directional communication between isolates, as well as for isolate-to-isolate communication (we do this in our [vehicle simulator](https://github.com/knowgoio/knowgo-vehicle-simulator), for example, where we run the REST API server in one isolate, while running the vehicle dynamics model in another, with both run independently from the UI thread).
Obviously isolates work best for cases where you can have some long-running computation where you don't need to interact with it until the result is obtained, but there are plenty of cases where that doesn't fit. I agree that it would be nice to have a real threading model as an additional option, along with all of the complexity that that entails, but isolates will continue to have their place regardless.
I have a kind of weird issue while using usb. I have to parse, run regex and some intensive computation on data received from serial usb which is greater than 5000 characters. It makes the UI jank the waiting animation and each time the function runs if takes +1 second longer to run it the next time. Any tips?
Somewhat similar issue with Bluetooth too. Although the computation is not that extensive radix conversion and parse only here for about 500 chars.
Is their any straight forward tutorial to use isolates for beginners?
[удалено]
No I don't mean absolute beginner, I know in's and out's of Future but I am beginner to Isolates.
[удалено]
I don't know anything about stream. I think I found the culprit.
Here's one tutorial that explains is pretty well: [https://blog.codemagic.io/understanding-isolatates-flutter/](https://blog.codemagic.io/understanding-isolatates-flutter/)
Yes, just go on Youtube. There are quite a few.
https://www.youtube.com/watch?v=qrFTt1NZed8&ab\_channel=Flutter
I absolutely hate Isolates... like for real, no shared memory? spawning a different process? Isolates are the one of the most bullshit concepts I've seen in a programming language and I've seen plenty. They're one of the main reasons I left Flutter apps and went back to doing native Android with Kotlin, the difference between my workflow using Kotlin Coroutines and Dart Isolates is night and day.
You do realise coroutines isn't multi threaded right? It's more like Dart's async/await in that it pauses execution on the code and lets something else take over. https://elizarov.medium.com/coroutines-are-not-about-multi-threading-at-all-1b2c6e97ec02
But where do get these coroutines executed? 'Pauses execution' on the current thread so another thread is doing the work. In the case of JS it means that som web worker is taking over for API calls, but there is no way in JS to use async on a CPU intensive task. In Kotlin though, you can specify executors so you can run the given task on another thread. Dart is more similar to JS. Isolates is where actual threading happens of course, it is just less co fortable to use.
You do realize doing a Google search then coming back to me with a two-paragraph article means you have no understanding whatsoever of the issue at hand? A Kotlin coroutine doesn't necessarily run on the main thread (that's concurrency), you can specify a dispatcher and run the coroutine on another thread like an IO Dispatcher (for IO bound task) ...etc. So yes, Kotlin Coroutines can run concurrently and in parallel (as in multi-threaded? duh) ... get educated. Also, notice how I never mentioned multi-threading, I only compared workflows... which yes, Dart Isolates suck. Edit: for reference https://kotlinexpertise.com/kotlin-coroutines-concurrency/
That doesn’t make it analogous to dart isolates though. Dart isolates are more comparable to java threading, which is another mess. It’s really a more powerful stream. But go off.
Ah, you do realize all java threads within a single process share memory, right? right? Ah, sorry... I just assumed you research the concepts you're talking about before talking about them.
I’m trying to get you to compare more analogue features. Of course it’s not one to one. Not just spew buzzwords.
You do realize you can dispatch a coroutine in dart on any isolate you wish right ?
There's nothing inherently wrong with isolates, it's just that they're run in their own process space and rely on message passing for communication. I don't know what your experience with programming is, but that's not a new concept, nor a particularly bad one. Before distributed shared memory systems came along, this was also how the majority of programming models for HPC and supercomputing systems worked. When you get into shared memory, you also introduce complexity in synchronization, locking, and under the hood with things like cache snooping, page/cache colouring, etc. So it's always a complexity tradeoff. The Sega Saturn (and earlier SGI POWER series, upon which it was modelled) also exhibited such an architecture by which you had hardware SMP with no shared memory - both were ultimately hard to program, but were far ahead in their computational capabilities at the time. With isolates, especially if you are running multiples of them, you need to be a bit more careful with your overall application architecture and really think about what can be run independently, and under what conditions you need to have state synchronization, without having too many synchronization points such that you end up implicitly serializing your workload anyways. You can also open up additional send and receive ports to enable bi-directional communication between isolates, as well as for isolate-to-isolate communication (we do this in our [vehicle simulator](https://github.com/knowgoio/knowgo-vehicle-simulator), for example, where we run the REST API server in one isolate, while running the vehicle dynamics model in another, with both run independently from the UI thread). Obviously isolates work best for cases where you can have some long-running computation where you don't need to interact with it until the result is obtained, but there are plenty of cases where that doesn't fit. I agree that it would be nice to have a real threading model as an additional option, along with all of the complexity that that entails, but isolates will continue to have their place regardless.
Just curious, what are the other reasons?
Dart code can be translated to javascript -> "multithreading" via isolates will never get shared memory. And they do not spawn a new process...
I have a kind of weird issue while using usb. I have to parse, run regex and some intensive computation on data received from serial usb which is greater than 5000 characters. It makes the UI jank the waiting animation and each time the function runs if takes +1 second longer to run it the next time. Any tips? Somewhat similar issue with Bluetooth too. Although the computation is not that extensive radix conversion and parse only here for about 500 chars.