High-level Architecture


#1

I’m trying to find a document that describes Atom’s high-level architecture, something that explains the relationship between the embedded “node” that exists somewhere inside Atom, the WebKit view that is obviously the UI layer and how these things tie together. Something analagous to the Chrome Extension “Overview” (https://developer.chrome.com/extensions/overview). If I googled wrong or searched wrong for using the wrong terms, forgive me!

I am curious about this because Atom “hangs” routinely for me. I’ve never had it happen out-of-the-box, but once I start making it useful to me with a few packages, it starts to occasionally stall out. This indicates to me that plugin code is allowed to run inside the “window” (or in Node) in such a way that runaway loops in some plugin somewhere can cause the whole system to come to a halt. Also, when this occurs I don’t get the option to “shut down the plugin”, or whatever. If atom were a web application that I was writing, I would force plugins into “web workers”, and expose the API in the form of messages, so that if they didn’t respond to a “hey, what’s up” in a timely way, I could prompt the user with “Oh, plugin was unresponsive, would you like to kill it?”, and not interrupt their typing. I don’t really know what the round trip time for this kind of messaging architecture is, so it might be “too slow” for typing-interactive packages, but building the “live” part and the “asynchronous” part separately would do a lot to fix this problem. I also can’t find any documentation for “standard” ways of running random JS off of the UI process, just ways of running normal system processes.

Anyway - thanks for an editor so good that I am inspired to improve it!


#2

I wrote this post a while back where I went through the Electron (at the time still called Atom Shell) startup process:

Some of the terminology is outdated, so be wary, but as far as I know it is still accurate in how everything fits together.

Yes, this is the problem with cooperative multitasking :grinning:

Eventually, Atom will probably go to a system like this if for no other reason than security.


#3

So it sounds like the basic architecture is “everything runs in the window, with cooperative multitasking, and everything has access to node packages”. This obviously has massive implications long-term. I’m glad to hear that there is at least a conversation happening to change this, but I am surprised to see that this fundamental of an architecture change is being contemplated once 1.0 is out the door… I don’t see a way forward that includes security AND support for existing packages.

So what’s the plan? Scope isolation could in principle solve some of the security problems, but not the cooperative multitasking fails. Is there a group/branch/something that is tasked with drawing up the structure for a “webworker” (for lack of a better term) architecture?


#4

Disclaimer: I am not an employee of GitHub nor a member of the Atom Core team. I’m just an enthusiastic volunteer.

There’s no plan so far that I know of. At least there isn’t one that is publicly communicated.

To be clear, when I said “eventually”, I meant “the team has said something about wanting to do this someday”. I doubt that the fundamental architecture is going to change in the near term. Right now it is up to the package author to ensure that their code behaves responsibly.


#5

While poking around to answer another question, I did find this in the Atom API documentation: