Has Unity considered having their IDE and the running game in separate threads, then at least when I do something that locks up my game I can stop it without waiting for days for the IDE to update?
I realise this is might not be a 4.x feature but with 5.x having a job scheduling system it should be possible.
This could also have the benefit of separating the IDE and game/scene views and allowing for a much more responsive IDE?
Iâd suggest separate process might be better isolation.
Either way could make writing editor extensions a bit more work, but especially separate processes as everything would have to be marshalled across process boundaries. In the first instance, thread safety would become a concern for everyone developing editor extensions and theyâd have to be mindful of it. Not that itâs a bad thing, but it adds complexity. All of that being said, many of the editor functions are actually multithreaded already.
Thereâs a lot of problems with this, for example editor scripts, which interact with scripts in the running game. For example a custom component, controlled within the editor. The solution in Unity 5 is just to give it to the jobs manager which deals with this best it can, mostly for things like enlighten and so on.
Iâll agree to this just because when working on a large scale project, it can take hours to open. When I worked briefly on *TDL it took like 40 minutes to open the source in unity. If the game crashed the editor, that was 40 another 40 minutes wasted! Iâd lose nearly an hour and a half of work time every day from that.
*I worked on it very briefly and accomplished very little, leading to a mutual termination as my education engulfed my life.
Somehow I donât think itâs possible without breaking a lot of the editor utility. I have to imagine there isnât any way to separate the editor from the running game or they would have done it already.
Seeing as how almost nothing within the Unity engine is currently thread-safe, I donât think there would be any way to be able to run the engine on a separate thread from the editor when all the components can be edited at runtime through the inspector.
I donât think itâd be as difficult as you think. Itâs just networking. The complexities of threading etc. can be hidden from the user.
The reality is Unity has a codebase which is monolithic. On paper itâs not difficult, but there are so many complexities and gotchas with an engine that was written from the ground-up without this in mind. Theyâre slowly moving more and more to it as time goes on, but itâs certainly not as trivial as you think.
Running the entire IDE on a separate thread to the engine would be difficult, but itâs not actually necessary; to deal with the âmy game is in an infinite loop and needs to exit play modeâ situation all we need is something that can interrupt mono on the main thread (making it throw an exception or something). Like how MonoDevelop can still attach and break.
This would be lovely and Iâd love to have it ⌠but I can see that this is not trivial at all - but as they are already going in that direction, maybe some day weâll get it 
⌠I doubt this will happen before Unity 6, though, if even ever 
I agree. If it was âeasyâ to let the inspector manipulate components from a separate thread, then it would be âeasyâ to manipulate components from a separate thread, period. But we know that theyâve been purposefully blocking the ability to manipulate almost everything within the engine from a separate thread since the beginning because of how un-threadsafe it all is.
If you say so.
Actually, it is pretty easy. (Or depending on your viewpoint, itâs completely unnecessary).
While there may be some gotchaâs (I donât do much editor scripting) Iâd want to see an example of difficulty before getting too worked up. Iâve done plenty of multithreaded stuff in Unity in the past, and itâs been pretty straightforward.
You constantly repeat along the lines of it being easy(which is kind of obvious; which makes it sound condescending). Weâre not talking about multithreading in a Unity game.
Hold on a minute are you saying the the editor and the game played by the editor are the same thing?
That would make separating and making thread safe the Editor and the Engine quite an undertaking.
I assumed that the IDE or Editor and the Game were separate, just running in a âdebugâ mode. So the Editor runs the Unity game engine after building the code for mono and displays the output to the game view.
But as previously stated if the editors UI âevent systemâ layer (or just the pause/play/stop buttons) was running on a separate thread that could interrupt the main thread then you could still have an Editor that does not lock up when the game is hogging resources.
[quote=âArowx, post:15, topic: 554155, username:Arowxâ]
Hold on a minute are you saying the the editor and the game played by the editor are the same thing?
[/quote]Theyâre all in the same process, running in the same AppDomain within Mono and so on, yes.
Haha, yes, now I remember, there was a thread a long time ago where you kept pretending you had figured out a secret way to access components on a separate thread, and we kept asking for an example but you wouldnât give any, and just kept saying it was âeasyâ. Well, in that case I would suggest just using the black magic you currently use to make the engine multithreaded and cast that spell at the editor window, and it should just work. Why bother Unity devs with it if youâve already figured it out?
The Editor has far more features than just pause/play/stop though. You can view and edit all components while the game is running with the inspector; you can do nearly anything that the editor usually does while the game is actually running and modify all variables on the fly, including custom components. It isnât based on an event system, it works by using reflection to directly modify values, and it adds/edits components the same way you would do it through code in an actual game script. Itâs a lot like a debugger. It has to constantly reflect all values of all components in the inspector window as the game is running, so it canât be a separate process unless you built in a whole async polling layer to get or set the values of every possible .NET object, which would be an ordeal to write and a large amount of overhead while running.
Well Iâm sorry, youâre just repeating itâs âhardâ which also sounds a little condescending and, kinda frankly, unenlightened. Unity does not prevent multiple threads working and Unity does not prevent multiple processes working together - this is pretty basic stuff that is done every day.
I agree, Iâm magic. I mean, itâs either that or you simply havenât bothered to spend a few minutes figuring out whatâs possible and prefer to make up fantastic scenarios to justify your inability to solve simple problems.
Hmm, so why exactly is this âblack magicâ again? This sounds an awful lot like networking and serialisation to me⌠you know that well established computer science that has a whole forum dedicated to it?
And is slow. So very slow. You really donât want to include the network and serialization for debugging an app if you can avoid it. Especially a game.