Parallet-My Dynamic Language-an asynchronous programming Language

Introduction:

Parallet is a new programming language developed by the author. it was originally positioned as an asynchronous script under DotNet to make up for C #'s lack of asynchronous programming. (I want to implement a number of super-complex server applications for asynchronous operations, but it is extremely difficult to use C .)

Just yesterday, the author completed the preliminary implementation of dynamic compilation to IL. compile most functions that do not require asynchronous execution into CLI. the performance of these functions is improved by more than 100 times after being converted from interpreted to compiled. (explain that the execution performance is similar to that of VBScript)

Basically, many architectural designs have been completed. The general direction is clear, and the rest are endless details.

Asynchronous:

In asynchronous programming, due to the characteristics of asynchronous functions in the new language, it not only supports traditional imperative programming, but also supports new asynchronous programming, developers can use traditional imperative syntax to write asynchronous operations, and get rid of all kinds of troublesome programming methods for Asynchronization.

In addition, in this new syntax system, functions are asynchronous by default. The system automatically analyzes which functions need to be processed asynchronously and which do not. therefore, this language does not create any keyword for asynchronous operations. it is very simple and easy to accept.

In fact, it is very difficult to describe this new asynchronous language at the moment. This is manifested in multiple aspects:

-The author's language level is very poor, and the expression ability is very poor. What he thinks cannot be well expressed.

-Similar to the traditional programming syntax, this is an advantage, but it also causes readers to think that this is basically irrelevant to asynchronous programming ..

-If the reader has not done asynchronous programming, he cannot know how troublesome asynchronous programming is,
I do not know the troubles of asynchronous programming, nor do I understand the advantages of asynchronous functions.

If the code is a document, it may be the best to use the code to explain the concept of this asynchronous function. The following is an example to illustrate the concept and significance of the asynchronous function.

Example:

In the following example, we try to make it simple and use the JS syntax by hand to make it easier for everyone to understand.

Traditional, blocking, synchronous call

Function LoadConfig () {var xhr = new XMLHttpRequest (); xhr. open ("GET", "config. aspx ", false); xhr. send (""); return ParseConfig (xhr. responseText);} the above Code is sent to xhr. if open is passed, a false value is specified as the sync Mode. when xhr. when sending ("") is executed, the current code will be blocked, the current thread will be blocked, and the browser will not respond.

In the UI thread, blocking occurs and the interface is suspended, which is unfriendly to users. To solve this problem, xhr provides an asynchronous mode.

Traditional, return style, asynchronous call:

Function LoadConfig () {var xhr = new XMLHttpRequest (); xhr. open ("GET", "config. aspx ", true); xhr. onreadystatechange = function () {if (xhr. readyState <4) return; ParseConfig (xhr. responseText);} xhr. send ("");} To xhr. if open is passed, a value of true is specified as async mode. xhr. after sending (""), the system returns immediately without blocking, but the program does not get the result immediately. after xhr receives a response from the server, it executes the onreadystatechange specified method to notify its callers to process asynchronous results.

At first glance, the two LoadConfig instances use different methods to implement the same thing, right? No!

Assume that someone has written such a piece of code:

Var config = LoadConfig (); InitMySystem (config. OptionName); the blocked LoadConfig can block the thread, wait for the server to reply, and return the result to its caller.

However, if you change the xhr in LoadConfig to an asynchronous call, config = LoadConfig () cannot pass the server results to config correctly.

Therefore, to solve this problem, the solution is to create a new function LoadConfigAsync.

Function LoadConfigAsync (callback) {var xhr = new XMLHttpRequest (); xhr. open ("GET", "config. aspx ", true); xhr. onreadystatechange = function () {if (xhr. readyState <4) return; callback (ParseConfig (xhr. responseText);} xhr. send ("");} and the code outside must be changed

LoadConfigAsync (function (callback) {InitMySystem (config. optionName) ;}); this method is the current situation of most programming languages. both JS, win32 asynchronous socket, and DotNet BeginXxx/EndXxx are passed back-sending functions (events are also passed back-sending functions ).

In this way, once the nesting between functions is more in-depth, it will become very complicated, and it is difficult to implement various loops, it is more difficult to implement, is how to handle asynchronous errors. in many cases, the code is split into many blocks. Basically, try/catch is required for each small block. It is also very troublesome to return results after handling exceptions.

Therefore, traditional asynchronous programming is not intuitive and troublesome. This is what Parallet hopes to solve.

In Parallet, all functions are asynchronous by default. Developers do not need to consider blocking or blocking. This is a problem that the language needs to solve for developers.

The above problem is written in Parallet as follows: (syntax form, XHR is fictitious)

// PARALLET code function LoadConfig () {var xhr = new XHR (); xhr. open ("get", "server. aspx "); xhr. send (""); return ParseConfig (xhr. responseText);} var config = LoadConfig (); InitMySystem (config. optionName); In Parallet, xhr. synchronization and Asynchronization are no longer required for open. it is asynchronous by default. however, xhr. after sending (""), the server does not return, the call chain will be suspended, and the current thread will not be blocked. the current thread will continue to run other tasks. when server. after aspx is returned, the current thread will run back again, continue to execute the ParseConfig part, and then return the LoadConfig result to the config variable to continue executing the outside code.

We can see that the main idea of Parallet is to release the current thread, do other things, and then come back to continue executing the code.

This seems simple, but the current mainstream languages cannot implement it directly at the CPU instruction or IL level. the main reason is that the current computer system uses stack to store various parameter return values and temporary variables on the function call chain. if the thread is to be released after half of the function execution, the operating system must store all the data on the stack. When the function execution needs to be restored, you need to recover the data to the stack and then let the thread continue.

The same is true for Parallet, which is not implemented on IL. Therefore, when Parallet executes an asynchronous function, it can only be interpreted and executed. All parameters return temporary variables, which are stored on special stacks of virtual machines, instead of the thread stack. that is to say, this process of data storage and restoration does not exist, but the performance loss is also very high. based on this interpreted virtual machine, any function can be suspended at any time, and the thread can switch to another task at any time.

Maybe you haven't seen the real benefits yet, because the example is too simple. If you set a try/catch layer on the outside, you can see the superiority of asynchronous functions.

// PARALLET code function LoadConfig () {var xhr = new XHR (); xhr. open ("get", "server. aspx "); xhr. send (""); return ParseConfig (xhr. responseText);} try {var config = LoadConfig (); InitMySystem (config. optionName);} catch (x) {alert ("initialize failed. ");} the above Code can be caught by errors in any link of asynchronous operations. if it is replaced by the traditional LoadConfigAsync, Should multiple split functions uniformly handle errors? Very difficult... very difficult... (infinite echo...), which is also the most annoying thing I use C # To write that server application.

Last

The code above demonstrates the differences between Parallet and traditional asynchronous programming. We can see that Parallet can greatly simplify the asynchronous problem.

No new syntax, no new keywords, everything is so simple, natural ..

In this mode, there is a very easy way to deal with various asynchronous, concurrent, multi-thread comprehensive issues. This will be added one after another.