Processes: Integration

[bryanjos]

I made a separate processes repo for the js processes library. It does a pretty good job of mimicking erlang processes. This will be included in the elixirscript repo.
https://github.com/bryanjos/processes

This also has an implementation of a GenServer as well.

It works well in JavaScript, but need to figure out a way of making it work for elixirscript. The biggest issue being how should functions be translated now? Also, what does it mean for interoperability with JavaScript (#170)? For example, we could turn all functions into generator functions, but how would that work when passing in a function from elixirscript as a callback to a JavaScript function?

[bryanjos]

Started working on this in the generators branch

[bryanjos]

This may go on the back burner for a while. Going through and changing everything to generators, things just didn't feel right. Operability with JavaScript libraries kind of goes out the window because a lot of them expect functions and not generators for callbacks. I don't think that is worth it.

So maybe back to the drawing board on this? Or maybe JavaScript interoperability can be reassessed?

[crertel]

In my mind, problem would be...what happens if an exception is thrown in JS land? What was your approach to handling that.

[bryanjos]

In the implementation above, the generator that is the process is wrapped in a try catch. If an exception is thrown, it's caught and goes through the flow of terminating the process.

[bryanjos]

An alternative is webworkers. They have most of the same properties of Erlang processes. The issues that would leave are how to handle importing scripts, as in how to handle which scripts should be imported into the web worker. Web workers can access the Dom so there would need to be special care for that as well. And also transferring any context if needed.

The import scripts part is complicated by the fact that js has so many module systems. Elixirscript targets es6 modules, but these still need to be transpiled, which may effect what and how scripts are imported. For instance, if using system.js, you would need to import system.js. and then there is the pathing problem.

Tldr; I really wish web workers could be the solution.

[crertel]

So, my first (lazy) attempt at solving that problem would be to have the runtime boot up some number of webworkers with a bootstrap script...just enough to get running and able to eval() a script sent to them via postMessage.

That done, you have a webworker pool that is sending messages around. The main worker thread (GUI) is where the DOM is manipulated. Comedy option: route messages that signify that they'll change the DOM to the GUI thread, where they are applied (via React or whatever).

The performance is a bit gross, but it should function as a proof-of-concept.

[bryanjos]

Your comedy option is a decent one. I've thought the same actually. Using a virtual-dom to manipulate in the web workers and then sending messages to the special UI thread to update the UI. It's not all that different from the design of a lot of mobile and native desktop UI frameworks.

I'm just not sure about the pool of web workers. I think I need an example. I've also been thinking if this is the way to go, then maybe forcing the compilation to a certain module system to make sure it works as expected.