Hacker News Reader

Comment by matt2000 | Hacker News Reader

matt2000

The project seems really interesting but I'm struggling to understand what the key benefits would be over other frameworks (Rails, Node, etc.)

Related question: Is multi-threading accomplished via these Isolates, or is there a threading model within each Isolate too?

Thanks!

View on HN

Good questions, thank you. Aqueduct initially started as a proof of concept - as a mobile shop, Dart was just so familiar to the languages we often used and it ran on the server. We tried building a few things and everyone was able to pick it up so quickly, and it took off internally from there. The value to us as mobile developers is that there was less context switching than when jumping into Ruby or JS (and all the other reasons we aren't quite fans of JS.)

Yes, multi-threading is accomplished through isolates. The application is run as a replica on a number of isolates, configurable by a command line option.

Each isolate has its own database connection, etc., but operate exactly the same. This behavior doesn't require any additional effort by the developer. (edit: The initialization code sets up a reactive channel for requests, each isolate instantiates that channel, and Dart's VM manages delivering an HTTP request to the most appropriate isolate.)

So, it's not quite like Erlang/Elixir where each connection gets its own process, rather the default number of isolates is 3. Isolates have their own heap, so memory isn't shared across them, but there is a message hub that isolates can send values across. This is useful when say you have websockets connected to different isolates and you want to broadcast a message to all of them.

You can spawn additional isolates from a 'web server isolate' to move computation to another thread.

Can an isolate handle multiple requests at once? (For example, suppose there are lots of cheap requests, so it's I/O bound, not CPU bound.)

How much extra memory usage is there per isolate?

An isolate is really just like a separate runtime, running in a separate thread. It's a language provided convenience (with some inter-isolate communication facilities but no shared memory). Think of it as running multiple node or python interpreter instances but with less hassle.

Yep, I was asking how Aqueduct is using them.

For a bit more detail:

The main isolate creates an Application instance that has N number of supervisors, one for each isolate. The isolates are launched and go thru their initialization steps, reporting back to their supervisor. The application completes its launch once all supervisors have reported back. It fails its launch if an isolate throws an error during initialization or does not hear back in a configurable timeout. Any inter-isolate messages sent during startup are queued until all isolates have completed startup.

Once the isolates are up and running, the main isolate doesn't do anything other than facilitate the inter-isolate message hub. Requests are delivered directly to the isolates running the web server.

When running automated tests, the default behavior is to run everything on the main isolate, since tests are run against a temporary database schema that only exists for the lifetime of the connection.

Yup! Each isolate has its own event loop... and I'll do a terrible job explaining that as its late in the day, so I included a reference link [1].

The memory consumption of an isolate depends on the size of the application code. Each isolate actually has its own copy of the application code that gets tuned by the VM over time. Even stuff like static variables are per-isolate. I just pulled up an OK sized Aqueduct project, and it looks like about 30-40MB per isolate. Most of that is probably Aqueduct itself. A worker isolate is likely an order of magnitude smaller.

1: https://webdev.dartlang.org/articles/performance/event-loop

Reply on news.ycombinator.com