I am a complete rust newbie, so take this with a grain of salt
Question is: now that the core is implemented in rust it might be worth thinking about moving the threads doing the message handling into core also? For C it was definitely the right decision to let the bindings deal with this, but as one of the main selling points of Rust is “Fearless Concurrency”
the project might be better off to only have one place to handle this?
This could minimize the work that specific language bindings have to do and would move one of the trickier parts into a place where a solid implementation is easier to achieve and maintain.
Indeed there are recurring discussions around this. The reason why threads are created from the UI is that it provides the UI more control over thread-creation and destruction. Also, special care needs to be taken how new threads interact with JNI/Swift-bindings and node-bindings. We might move towards a model where all events are emitted from a single “event dispatch” thread that is created by the UI. This means that all callbacks (i.e. events) into UI code would arrive in the same thread, serialized.
