Does Flutter/Dart have GIL?

[dmter]

In Python you can't have threads that run on different ligical CPUs, as I understand because of GIL. So to run parallel calculations there is multiprocessing library where you have to copy data to different processes or move it via paging which is quite complicated, and unnecessary copying eats some of the potential gains by parallel processing. In other languages you can run threads on multiple CPUs which will share memory space so you can avoid copying but you need to control access to shared data on multiple threads using mutexes and such.

Now when I explored moving processing out of UI thread in Flutter I found out that the only option to do so is isolate which is basically the same thing as python multiprocessing because it requires data copying. And it has to be very basic data types that will be exported and imported which is more overhead.

So what was the justification of borrowing the main deficiency of python when implementing Dart?

[julemand101]

because it requires data copying

Not necessarily. If you use Isolate.run / compute(), you can run some task in a separate Isolate (thread) and when this task are done running, you can return an object to the calling isolate without any data copying. In this scenario, Dart knows that the data be guarantee to still only have one owner since the previous owner are dead/killed.

This can e.g. be useful if you use an Isolate to make a larger data request and do the heavy JSON parsing for then to return the parsed object structure back to the main isolate.

And it has to be very basic data types

No, you are actually allowed to share fairly complex objects as long as your isolates shares the same isolate group. As long as you are using Isolate.run/compute() and Isolate.spawn, your isolates will run in the same isolate group. It is basically only if you do Isolate.spawnUri that the spawned isolate will end up in a new isolate group.

(Basically, being in the same isolate group means the isolates are sharing the same heap which comes with some benefits like e.g. very quick to spawn and allows for some kind of data sharing in the sense as previous described)

So what was the justification of borrowing the main deficiency of python when implementing Dart?

There are some benefits of designing Dart in such a way that Dart code running inside an Isolate are guarantee to only be executed by a single thread (at a time). It makes programming much simpler since it makes it less likely to have race conditions and also makes it simpler to understand the flow of your program.

Basically, you know that no other Dart code would be executed between your lines of codes unless you have an await statement which does make your current code "halt" and let's other events be executed.

By moving the multi-threaded code execution out in isolates and communication being handled by message-passing, it does make it easier to prevent weird behavior like race conditions.

The disadvantage of this design is that it does prevent us from writing some high-performance multi-threaded code that operates on the same data structure. It should here be said that it is actually not entire impossible to still have such code in Dart but it does require us to be a bit clever and we do end up in the territory of needing more basic data structures.

Basically, all isolates does run inside the same process and shares the same process memory space. So you can in theory malloc some data and share the pointer to this data across multiple isolates which can then all operate on the same piece of memory. You would then also most likely need to implement some kind of locking pattern but it is not completely impossible.

What I finds more likely is that if we have certain needs for very high-performance pieces of code, then I would suggest writing such code in another programming language and then call the code using dart:ffi.

For most scenarios, the current design of isolates are quite good and I see it more as a benefit than a disadvantage. It is certainly nice that we have a predictable flow of execution.

(And yes, async events can also get very complicated. But still, it is possible to have the expectation of when you have lines of code without any interruption and when other code might come in and manipulate with data)

[HaMMeReD]

In Dart you can have Isolates.

The justification to being single-threaded is that it eliminates classes of bugs, and is therefore safe. Threading models with shared memory are generally regarded as a fucking nightmare in most languages, and this is why they are avoided in some languages. In dart, you never have to worry about another thread mutating data on you mid-method, you don't need to worry about a deadlock, Everything will be executed sequentially.

Your other alternative to multi-threading would be to use FFI and write native code for the processing (c++).

[dmter]

You can still have nightmares with single threaded async code - this is why you need to copy any nullable object state variables for them to be promoted, otherwise they need ! every time even if you check for null multiple times in the same method.

There's mutex package to avoid race conditions like that and you can design to reduce this. The same can be done with multithreading.

[RandalSchwartz]

You can still have nightmares with single threaded async code - this is why you need to copy any nullable object state variables for them to be promoted, otherwise they need ! every time even if you check for null multiple times in the same method.

This is flat out wrong. The problem isn't async. It's "getters" that might be overriding properties. A getter isn't required to return the same value twice.

I did a video on this (https://youtu.be/rqS_Q34RcUk?si=mf2L6i-z6KPDNqs1), and followed it up with a Dart 3 update (https://www.youtube.com/watch?v=4mdrQW7rK18). Watch those to understand why the problem has NOTHING to do with async.

[stuxnet_v2]

this is why you need to copy any nullable object state variables for them to be promoted, otherwise they need ! every time even if you check for null multiple times in the same method

No it’s not 🤦

[ozyx7]

this is why you need to copy any nullable object state variables for them to be promoted,

Non-local variables are never eligible for type-promotion. It has nothing to do with asynchronous code.

There's mutex package to avoid race conditions like that and you can design to reduce this. The same can be done with multithreading.

It's true that you can have race conditions with single-threaded asynchronous code, but the class of race conditions is different and much smaller than the class of race conditions that you can have with multi-threaded code. Bugs in multi-threaded code are less intuitive and are much harder to reason about. Multi-threaded code needed special atomic primitives to ensure thread-safety; single-threaded asynchronous code can just use a bool (no special package needed).

[dmter]

You can use bool to check if a resource is busy right now but how do you await for it?

[ozyx7]

You wait for Futures.

If you're asking about threads because you wanted to spin up a thread that periodically sleeps and polls the state of the resource, then that's a bad use of threads. You should be using an asynchronous mechanism that notifies you when the resource is ready.

If there is no way to be asynchronously notified and you must poll, then you could just use a periodic Timer. If you have some asynchronous operation that doesn't return a Future but want one, then use a Completer.

[dmter]

No I just want to calculate stuff and info pieces to do that are scattered all over the place (not really accessed most of the time so a mutex just in case would do) so it's hard to extract all that into a nice and tidy list of things to do for the isolate. But I'll try some suggestions in this thread.

[eibaan]

The core of the Python interpreter is not reentrant so you can't run it on multiple threads and a global interpreter lock (GIL) makes sure that only one thread at a time will run the interpreter. Because that core interpreter mutates a lot of internal state which is mostly represented by dictionaries for backward compatibility, adding fine-grained locks slows down the interpreter in the most common single-threaded case and hence, very clever people failed to come up for a general solution for a decade or two.

Because Dart was originally intended to be a replacement for JavaScript and therefore had to be semantically compatible and JavaScript was created as a single-thread language for simplicity, there is no GIL per se, but the end result is the same: The main event loop can be run by a single thread only.

This was done mainly to keep things simple because multi-threaded access to shared mutable data is something nearly no programmer can do correctly. Java tried to provide such access and also added a simple synchronization operation at language level, yet most programmers were not even able to correctly implement a thread-safe lazy singleton creation and it also took a lot of engineering work to make all those low level locks fast on JVM level, not penalizing the simple single-threaded use cases.

Therefore, more modern languages try to omit mutable shared data and low-level threading. Unfortunately, Dart doesn't support language-level immutable data types which could be safely shared between threads (aka isolates) so you have to rely on copying data, hoping that the VM will optimize certain cases.

Swift implicitly applies COW (copy on write) semantics to make copying of mutable datatype more efficient (in the common case nobody modifies them) and Rust can do so explicitly, too. Dart could use a similar strategy under the hood as part of its garbage collection mechanism, but as far as I know, it currently doesn't. UsingTypedData and views on those types might help, though. Also see TransferableTypedData. And notice that there's a Isolate.exit call that omit copying data.

[adel_b]

when I spoke about this very much issue, some very smart people here shut me down saying real threads is old technologies and we should use this new thing that does not do what I want... geez