Patent Grant
11983516
This Application is a Section 371 National Stage Application of International Application No. PCT/EP2019/079179, filed Oct. 25, 2019, which is incorporated by reference in its entirety and published as WO 2020/089076 A1 on May 7, 2020, not in English.
The invention relates to the field of computer code processing. More particularly, the invention relates to processing so-called script codes. This consists of a code that is interpretable and/or executable via a virtual machine or an interpreter. More specifically yet, the field of the invention is that of optimisation of script code execution within a dynamic execution environment.
It is common, in particular in an institutional context or in enterprises, to have complex computer systems architectures, involving the implementation of numerous devices (computers, servers, mobile devices), interconnected by one or several communication networks. Within such organisations, the number of devices that are connected to one another is growing steadily and maintenance of these hardware and software architectures is expensive. In an attempt to save on these costs, enterprises also resort to so-called “cloud” services, for example in order to implement SaaS (standing for “Software as a Service”) or AaaS (standing for “Application as a Service”) type solutions. Although they actually allow limiting maintenance costs related to directly-owned architectures, these solutions are not devoid of other constraints (in particular pertaining to data security or to performance).
As regards performance, regardless of the solution that is retained by the organisation, this is often assessed with regards to the expectations of the users. When the organisation possesses its infrastructure, the need for performance, in particular for the execution of server or client-server applications, requires the purchase of increasingly powerful hardware, fitted with more and more resources (processors, memory space, rapid disks), in order to address the needs encountered by the users.
Yet, although some applications or some programs are actually capable of fully using the resources made available by the new hardware, others are often unable to do so. Indeed, programs and applications may be divided into two main categories (later on we talk only about programs). The first is that one relating to compiled programs; these are programs whose source code (written for example in the C, C #, C++, Pascal language, etc.) is transformed, using one or several compiler(s) and/or one or several optimiser(s) into an executable code for a determined platform (a platform being understood as a processor architecture and/or an operating system). These compiled programs are effective as they are capable of taking advantage of all of the resources provided by the platform on which they are executed. This effectiveness finds its origin in the numerous published works allowing optimising a binary code according to the destination platforms (for example use of all of the processor cores that are available, parallelisation, common use of the memory, etc.).
The second category is that one relating to interpreted programs; these are programs whose source code is interpreted before being executed. Among the popular programming languages of this type, mention may be made for example of PHP, JavaScript, or bytecode Java. In the context of the invention, the term script code is used to refer to the code of a program written in a language of this type. The advantage of programs that are written in these languages is that they are multi-platform: the script code of the program is executed in the same way on different platform types. Only the interpreter is optimised for a determined platform. This considerably facilitates the spread of programs. However, the performances of this program type are often inferior to those of binary programs, even when carrying out a dynamic compilation. And the reason is that, although numerous works have been conducted to improve the operation of interpreters and virtual machines, these have not always led to fully satisfactory results.
For example, the JavaScript language allows writing programs (scripts) that are executed by a JavaScript engine (or JavaScript interpreter). Such an engine is either embedded within a Web navigator (Firefox™, Chrome™, Edge™, Opera™), or implemented separately within a dedicated interpreter (for example Node.js™). As is the case with other languages, the JavaScript code is historically a language that is executed in a mono-thread environment (that is to say all events are performed one after another). When a long function is implemented by the interpreter, the latter is not necessarily available to perform other tasks as long as the function is not completed. Of course, with the recent evolutions embedded within the interpreters, it is possible to create isolated execution streams via available interfaces (for example the “webworkers” in the navigators) or in Node.js (webworkers, child.spawn/fork). Thus, theoretically, there are solutions to carry out a remote function call within an execution stream different from the main stream. However, the main problem lies in the scope of the code executed in another execution stream. Indeed, to be able to operate properly, these existing solutions, such as those mentioned before, shall be embedded within the script source code during writing thereof by the developer. For example, the webworker call shall be provided in advance by the developer of the program who must therefore know, well ahead, that the program is likely to be executed over a long period and that it is therefore necessary to provide for one or several execution stream(s) for the execution of the program. Each execution stream (each webworker) implements a code that is specific thereto (and defined by a particular JavaScript file). Hence, there is no dynamism in the creation of a webworker, and even less dynamic load distribution. Moreover, the execution streams are independent of each other. This means that these do not allow managing the correspondence of the objects between the caller and the called because the existing solutions perform objects replications (when they do so), and neither do they allow managing the entire extent of applicability of the variables and functions within the different execution streams.
Hence, there is a need to provide a solution that does not pose the aforementioned problems and which allows taking advantage of more available resources within the information processing infrastructures.
The method suggested by the inventors does not pose these problems of the prior art. Indeed, a method is provided for executing a script code of an application, the method implemented via an electronic device, called calling resource (ResA, A), within which said application is executable. According to the invention, such a method comprises:
subsequently to the execution (50), by the destination execution resource, of at least one function of said at least one projectable object, the transmission data structure; a step of receiving (60) a data structure (ExObj, diff) of execution results of said at least one function;
Thus, the invention enables the execution of a script source code on multiple resources without requiring, on the remote resources (destination execution resources), the implementation of a process that is different from that one usually implemented for the execution of a script code by one of these destination execution resources. Thus, in at least one embodiment, the invention allows performing a script code execution “distributed” over several execution resources. The transmission of the entire script code to the destination resource is no longer relevant. All it needs is to transmit a portion that is independent and executable in a standalone manner to implement the described technique, which simplifies the distribution of the treatments. Moreover, the transmission data structure associates to each projectable object of the script code, an indexing data, which shall be understood as an indexing data of the projectable object. In particular, the preparation of the transmission data structure comprises indexing the transmitted objects.
According to a particular feature, the step of integrating execution results of the execution results data structure within the calling resource comprises a differential verification of the integrity of the data updated during the execution (50), by the destination execution resource.
Thus, it is possible, within the calling resource, to ensure that the remote execution results do not conflict with other (local or destination) resources that might have modified the same data prior to the reception of these modified data by the destination execution resource. Hence, propagating or integrating inconsistencies in the processed data, when these are at least partially processed remotely, is avoided.
According to a particular feature, the step of obtaining the script code comprising a set of projectable objects comprises:
Thus, the script source code is not directly transmitted to the resources to be executed. Instead, it is analysed so as to determine which code portions are prone to be projected towards destination execution resources, possibly by modifying the script source code itself.
According to a particular embodiment, the step of preparing a transmission data structure of at least one projectable object of said script code comprises:
Thus, by using two different data structures, on the calling resource side, to index the execution script code that is transmitted, it is ensured that it is possible, once the code executed by the destination resource is completed, to find back an object correspondence that is identical to that one which has been transmitted, and therefore a verification of the data received from the destination execution resource is made possible.
According to a particular embodiment, the step of receiving a data structure (ExObj, diff) of execution results of said at least one function comprises:
Thus, it is possible to track the evolution (the modifications) made on the data, independently of the structuration of the transmitted data, while preserving the indexing performed at the input of the process during the creation of the data intended for the destination execution resource.
According to a particular feature, the step of integrating execution results of the execution results data structure (ExObj, diff) within the calling resource comprises:
Thus, it becomes possible to check the preservation of the semantics, both on the code as well as the data that are transmitted and sent back by the destination execution resource.
According to a particular feature, the step of modifying the script source code, delivering an execution script code comprising said set of projectable objects, according to said at least one projectable function determined beforehand comprises:
Thus, it is ensured that the code projected towards the destination execution resource can be executed with a context identical to that one of the local resource. In fine, this allows ensuring a more effective operation of the projected codes, by minimising possible execution invalidation operations.
It should be understood, in the context of the description of the present technique according to the invention, that a step of transmitting a piece of information and/or a message from a first device to a second device, corresponds, at least partially, for this second device to a step of receiving the transmitted information and/or message, whether this reception and this transmission are direct or performed via other transport, gateway or intermediation devices, including the devices described hereby according to the invention.
According to another aspect, the invention also relates to an electronic device for executing a script code, called calling resource. Such a device comprises:
According to a complementary aspect, the invention also relates to a system for executing a script code. Such a system comprises at least one calling resource in the form of an execution electronic device as described at at least one remote resource, in the form of a script code execution resource accessible from the calling resource.
According to a preferred implementation, the different steps of the methods according to the invention are implemented by one or several computer software or programs, comprising software instructions intended to be executed by a data processor of an execution device according to the invention and being designed so as to control the execution of the different steps of the methods, implemented at the communication terminal, the execution electronic device and/or the remote server, in the context of a distribution of the treatments to be performed and determined by a script source code.
Consequently, the invention also covers programs, prone to be executed by a computer or by a data processor, these programs including instructions for controlling the execution of the steps of the methods as mentioned hereinabove.
A program may use any programming language, and be in the form of a source code, object code, or an intermediate code between a source code and an object code, such as in a partially compiled form, or in any other desired form.
The invention also covers an information medium readable by a data processor, and including instructions of a program as mentioned hereinabove.
The information medium may consist of any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM, for example a CD ROM or a ROM of a microelectronic circuit, or a magnetic recording means, for example a mobile medium (memory card) or hard disk or a SSD.
Besides, the information medium may consist of a transmittable medium such as an electric or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. In particular, the program according to the invention may be downloaded on an Internet-type network.
Alternatively, the information medium may consist of an integrated circuit within which the program is embedded, the circuit being adapted to execute or to be used in the execution of the considered method.
According to one embodiment, the invention is implemented by means of software and/or hardware components. In this respect, the term “module” may correspond in this document to a software component as well as a hardware component or to a set of hardware and software components.
A software component corresponds to one or several computer program(s), one or several subprogram(s) of a program, or more generally to any element of a program or software adapted to implement a function or a set of functions, according to what is described hereinbelow for the considered module. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is prone to access the hardware resources of this physical entity (memories, record mediums, communication buses, in/out electronic boards, user interfaces, etc.).
Similarly, a hardware component corresponds to any element of a hardware set adapted to implement a function or a set of functions, according to what is described hereinbefore for the considered module. This may consist of a hardware component that is programmable or with an embedded processor for the execution of software, for example an integrated circuit, a chip card, a memory card, an electronic card for the execution of a firmware, etc.
Of course, each component of the previously-described system implements its own software modules.
The different embodiments mentioned hereinabove can be combined together for the implementation of the invention.
Other features and advantages of the invention will appear more clearly upon reading the following description of a preferred embodiment, provided merely as an illustrative and non-limiting example, and from the appended drawings, among which:
As indicated before, an object of the invention is to enable an effective use of execution resources available within an infrastructure, in the context of execution of script programs by an interpreter or a virtual machine. More particularly, the invention enables the execution, remotely or locally, in a plurality of execution streams (an execution stream belonging to the group comprising a processor thread, a processor, a processor core, a script language thread, an execution context of an instructions sequence), of one or several portions of applications. Thus, the invention enables a dynamic integration of execution resources (servers, personal computers, smartphones and tablets) and the dynamic allocation of portions of applications to the newly integrated execution resources.
The invention provides a simple and effective solution to the aforementioned problems. In particular, in the context of a one-server environment, the invention offers the possibility to automatically use all resources available within this server (using all of the cores of the available processors). In turn, the identification of the code portions to be distributed is either automatic, or manual. In the context of a multi-server use, the invention allows distributing codes portions executable between several servers in order to implement the execution resources available within these servers. Third, the invention also allows distributing codes portions executable over different devices (personal computers, tablets, smartphones) connected via one or several communication network(s).
For this purpose, the invention is based on the implementation of a specific software module, which is used in a supervised mode or in a peer-to-peer mode. In the embodiment described later on, the supervised mode is detailed. Referring to
This software module (XStrmr):
These last five steps are implemented by the allocation unit (AllocU).
The execution streams are initialised before the transmission of the projectable code portions. This means that when a projectable code portion is transmitted, an execution stream able to execute this projectable code has already been initialised.
Thus, in general, the calling resource is capable of decomposing and/or modifying (whether automatically or not) the original application, into portions (pieces) that are executable independently of each other, and is then capable of transmitting these portions (and their execution context) to an identified resource, which executes this portion, using the transmitted context, and sends back the result to the calling resource for processing. More particularly, according to the invention, an execution streams management method is implemented in particular, the method comprising a process for saving the code portion (before transmission thereof to the destination resource) and a process for managing the scopes (of the variables in particular, also called scopes management process) and that being done in order to ensure consistency of execution of the code in the destination resource. These two processes allow certifying that the codes portions executed by the remote resource preserve the semantics, on the code as well as the data (and therefore they provide a result that is identical to that one which would have been obtained if these portions have been executed by the calling resource).
More specifically, the execution streams management method is implemented, within the aforementioned software module, using the compilation units and the allocation units. This execution streams management method allows preserving, in the different streams created for the projection of the code portions, a unified execution repository, which is used to ensure unicity of the execution. In other words, according to the invention, the execution of the different projected codes portions in the parallelised execution streams is transparent for the application. The latter is not aware that it undergoes a decomposition into several portions executed independently of each other by different resources, within different execution streams: from its perspective, everything proceeds as if the treatment has been carried out within the same execution stream. This is advantageous in many respects. In particular, any application can be executed by the software module object of the present technique. In particular, it is not necessary to write the application in a specific way. A decomposition assist interface may be implemented later on in order to guide the decompositions. However, the developer has only to write the application as he wishes, according to his own requirements. The software module analyses the code of the application, according to specific analysis parameters and determines alone the code portions (functions, procedures, modules) to be projected in parallel execution streams. The developer has to learn any interface or to develop in a specific way.
In other words, in order to ‘parallelise’ a program, during loading the program, the compilation unit identifies (and/or builds) the potentially parallelisable functions and generates the necessary instrumentations so that these could be subjected to the allocation unit.
For the execution, the allocation unit relies on three functional blocks (these blocks may potentially be integrated into one single program): service, master and runner. A runner materialises the streams. The master the projectable functions placement strategy. The service supplies the code to be executed in the cluster.
In order to execute a function on a destination execution resource:
A specific embodiment of the proposed technique is described later on in connection with the script language “JavaScript”. Of course, this embodiment in the context of the JavaScript language is disclosed as example and it does not limits in any way the technique itself, which can be implemented in general in any script or interpretable language, such as PHP, or bytecode (java or others).
In general, according to the invention, the script code is split/modified/structured, into one or several pass(es), by the compilation unit of the software module. Once structured into projectable code portions, the allocation unit of the software module decides, on the fly, on the execution of code portions using other available resources. Thus, beforehand, it is considered that the software module is capable of obtaining or detecting one or several available resource(s), locally or remotely. The manner in which this detection is performed is not part of the object of the invention. The only important feature being that a server (for example the local resource) has knowledge of the available resources.
Based on the code split into projectable portions and on the plurality of available resources, the software module:
It should be noted that the previously-defined operations, in particular the operation of identifying the destination resource, may be carried out upstream, like the definition of the exchange data structure.
In other words, the technique hereinabove consists of a modification of the serialisation, which no longer consists in transmitting the serialised objects as such, but in transmitting a different data structure, derived from the objects to be transmitted, this data structure is built by the calling resource, based on the objects (and functions) to be projected, and is then, in turn, transmitted to the destination execution resource. The destination execution resource creates all of the objects based on this projected data structure and updates this projected structure (when the functions or objects modify appended values) and creates a complementary difference data structure, which lists the data that have been modified throughout the execution of the functions. Once the treatments are completed, these two data structure (the original structure and the differences structure), are sent back to the calling resource, which, based on the modifications that have been made, performs the updates of the objects (and of their data) to reflect the execution that has been completed within the destination execution resource (when some properties shall be met and are actually met, for example the ACID property, as described hereinbelow).
For example, the data structure is built by serialisation. The serialisation allows building a machine-independent data structure that can be transferred on a network protocol and after reception, carrying out an instantiation in order to rebuild the original data structure.
According to the present technique, the decomposition, identification, creation, projection and results processing treatments are implemented iteratively and/or recursively throughout the execution of the application.
In this embodiment, the implementation of the technical principles previously described in the JavaScript language is described. More particularly, the manner in which the execution contexts, the scope management, and the preservation of the ACID properties of the executed code are managed in the JavaScript language is described.
5.2.1. Execution Medium in Different Streams
The JavaScript engines enable the creation of isolated execution streams via interfaces available in the navigators (for example the webworkers) or in Node.js (webworkers, child.spawn/fork). The method described herein allows carrying out a function call from an execution stream A in a second execution stream B whether this is local (on the same computer) or remote (on another computer) while preserving a unified execution context. The method allows providing unified remote execution functions and opens up the field for application of the remote execution to any function and without limitation.
5.2.1.1. Correspondence of the Object Systems
Basically, in order to enable a unified execution, it is necessary to provide a solution for tracking the modifications made on the objects by the called function and to maintain the objects systems of the stream a and of the stream B in correspondence.
When a JavaScript stream A creates a stream B, the execution streams are isolated to the extent that no property or objects of A are accessible by B. The only way for A to communicate properties or objects to B is to use a communication means between A and B (IPC). Thus, the data transmitted by A are replicated in the space of B. B can use them as it sees fit as there is no link between the data of A and the data of B. Conversely, B can use an IPC to communicate properties or objects to A.
In order to transmit objects, a serialisation of these is performed, and then once received by the destination execution stream, instantiation thereof is performed in this destination stream. In
It is worth noting that this way which can be used in JavaScript allows exchanging objects, but it has the major and restrictive drawback of losing the correspondence of the objects between the streams A and B. For example, the stream B does not know (has no knowledge of the fact) that Ob corresponds to Oa, and that Xb corresponds to a Xa.
The technique that is implemented by the inventors creates the illusion that the function that is executed in the stream B is executed in the stream A. Also, it is possible to maintain an equivalence of the objects so as to be able to update the modifications of the objects within the actual objects of the stream A. For this purpose, the inventors have defined a solution that extends the serialisation and the instantiation in order to preserve these links. This solution comprises several steps, illustrated with reference to
Step 0 (S0) consists of an extension of the serialisation:
Thus, refA[0] and heapA[0] are associated to Oa and refA[1] and heapA[1] are associated to Xa.
During the communication (serialisation) performed between A and B, only heapA is transmitted.
In the figure, the table heap is represented only once for more clarity in the presentation.
Step 1 (S1) corresponds to the step of instantiation of the objects within the stream B. On B:
Thus, after instantiation, the content of the table refB of the stream B allows making a correspondence with the content of refA of the stream A (for example, it is known that refB[1] on B refers to refA[1] on A).
At this level, the stream B is capable of executing one or several function(s) present within the objects Ob or Xb. For the example described herein, these functions read and/or modify the new objects (Ob, Xb) and instantiated parameters. For example, the stream B changes Ob.p1 from the value 12 into the value 24 and associates a new object Yb to Ob.p2. Moreover, Xb.p1 is modified from the value 13 into the value 243. For this purpose, the stream B uses the heap received from A. Either A has deleted the heap on its side, or A has preserved the heap on its side, depending on the operational conditions of implementation.
Step 2 (S2) carries out a calculation of the differences (following the execution of the functions):
Once the function(s) is/are executed, it is possible to scroll the table refB and check thanks to the heapB whether a property of the object (Ob, Xb) has changed or not. During this scrolling, a table diffB is thus created which contains the list of the differences. In the case of a change into a new object, a new index is created in heapB in order to materialise the new object. Thus, the table diffB contains for the object 0 the new value for p1 (that is to say 24) and the new index (2) of the object created in heapB for p2 (refYb). It will also contain the new value of the property p1 of Xb (namely 243).
Assuming that Ob contains another property (p3) and that its value is unchanged, it will not be described in the table diffB. The table diffB does not contain the modifications on the objects (object addition, object modification (modification of a property, deletion or addition of a property).
Once the calculation of the differences and the update of heapB is completed, diffB and heapB are transmitted to the stream A (that is to say it is serialised and transmitted to the calling stream A). It is also possible to transmit only diffB and just keep heapA on the calling resource (that is to say heapB is not transmitted at the same time as diffB at the end of the execution on the stream, only diffB is transmitted: this relieves the transmissions, but puts more memory pressure on the calling resource).
Step 3 (S3) instantiation of the new objects on A:
Upon the reception of diffB, A (Step 3) instantiates all of the new objects inserted in heapA, and adds the references in the table refA.
The ACID property of the objects can be checked on completion of this instantiation (cf. hereinafter);
Step 4 (not represented) update of the objects on A:
The last step using the table diff, A updates the content of the objects of A.
As indicated in the diagram, all of the objects have been built between A and B and the modifications have been reported in the object space of A.
It should be noted that steps 0, 1, 2, 3 and 4 are respectively executed within the streams A, B, B, A, and A and that during these steps, nothing else can be executed within these streams.
It should also be noted that if the object Xa is accessed to by another object other than Oa, the new value of Xa has been propagated. If Xa is referenced only by Oa, then following the update, it will be collected by the garbage collector of the virtual machine.
5.2.1.2. Actual Functions Calls
Thanks to the previously-described method, the inventors have the means for maintaining the equivalences of the objects systems between two streams, which has not been possible before.
In order to carry out the function call, all of the input parameters of the function are serialised. Then, once executed, output parameters are added in the serialisation, according to the same mechanism. Thus, it is possible to call a function while maintaining the objects related to the input and output parameters.
5.2.1.3. Management of the Scopes
Besides the parameters, a function may need to access properties/objects that are accessible in its scope, that is to say properties/objects, that although are not defined within an object to be transmitted to the destination execution resource, are nevertheless accessible in the initial script code. This is for example the case of global variables, variables or properties of a previous level or else parent objects (during objects inheritance for example). Thus, a problem to be solved in order to be able to perform a transfer towards another stream is also to be able to perform an execution context transfer, the context comprising the set of properties/objects to which the function has access during execution thereof. The determination of this context is performed upstream, that is to say before transfer towards the destination execution resource, normally by the compilation functional unit. The created context is part of the objects that are serialised and transmitted by the previously-described transmission method.
Thus, in order to transmit the context of the environment to a remote function call, two possibilities for processing the scopes are possible: either being in an execution phase to be able to access the environment and transmit it directly, or rewrite the script code in a particular way.
A first solution consists in simulating the JavaScript context.
In this first solution, in order to transmit the context without the assistance of the interpreter (for example without the assistance of the JavaScript engine), it is necessary to create the context in the selected language (for example in JavaScript). For this purpose, it is necessary to know all scopes of the variables, of chains of scopes and all accesses to the context. In order to do so, we shall exclude every dynamic scope, that is to say the use of keywords such as “with” and “eval”, and therefore be within a purely lexical scope. The creation method comprises:
Using this first solution, consisting in rewriting the code and defining a transmission context which is associated to the different scopes, transmitting and executing a function at a destination execution resource is easy: all it needs is to transmit the function object, which contains the entire execution context of this function via its symbolic property ‘context’.
A second solution consists in capturing the context and falsifying it.
In order to be able to implement this solution, we shall exclude every dynamic scope, that is to say the use of keywords “with” and “eval”, and therefore be in a purely lexical scope.
A number of alternatives may be imagined using utility functions, herein also, the transformation shall be careful with regards to names conflicts with its own variables, but the transformation knows all scopes, and can therefore avoid conflicts easily.
In order to project a function with this alternative, the program shall obtain the context object from the function to be projected by calling the function pointed by the property captureUpdate of this same function. It shall then serialise this context object with the same mechanism as described before. After executing this function, the program shall update the context thanks to the context object derived from the deserialisation that it will transfer to the function pointed by the property updateContext of this same function.
5.2.1.4. Consistency of the Objects, ACID Execution of a Function, Ordered Execution
In the previously-described case, a function executed in another execution stream (on a destination execution resource) modifies the objects transferred into parameters. Given the fact that this function can be executed in an asynchronous and parallel way, the execution stream A (calling resource) or another execution stream (other destination execution stream) can meanwhile modify the same objects. This is not possible in a standard JavaScript system wherein all functions are executed in the same stream. In order to maintain the consistency of the objects, the functions shall, by default, preserve the ACID (Atomicity, Consistency, Isolation and Durability) properties. Hence, the inventors have developed a technique for preserving these ACID properties. Thus, in order to execute an ACID property of the function, a differential validation is performed, which consists in particular in checking that:
For this purpose, the previously-described step 2 (S2) is reused, but applied on the stream A. If the table diffA is empty, then no modification has been made during the execution of the function, it is proceeded with the commit (the validation) of the function and the object system of the stream A is updated (steps 3 (S3) and 4). If the table diffA is not empty, then the function executed by the destination execution resource is invalidated: the updates of the parameters and objects are not propagates and the function is executed again.
Thanks to this differential validation, it is possible to execute a function, in an asynchronous and parallel way, in another stream, while maintaining its execution coherent in the initial application. Moreover, it should be noted that executing the function again in an asynchronous way does not pose any problem because the function to be executed itself is asynchronous.
Another property to be met is the asynchronous execution order relationship that is defined only by setImmediate.
For example, the following sequence:
Presupposes that f1 will be executed before f2, and that f2 will be executed before f3. Also, in the case of a remote execution, as described before, if f2 or f3 finishes before f1, it is necessary to wait for the validation (the commit) of f1 before doing the commit of f2, and then f3. In which case, the method allows identifying these cases by carrying out a specific pass especially for these aspects during the decomposition of the script source code. Moreover, during the execution, a sequencing of the validations (commits) is performed in the activation order and/or the invalidated functions are invalidated/re-executed where necessary.
Hereinbelow is a simple example showing the use of this order relationship. The order relationship is necessary in order to obtain the proper result induced by the causality of the variables of the code.
In this example, if the order is observed, the result amounts to 7; if the order is not met, it amounts to 9.
In the case of this example, on the one hand, the compiler (the compilation unit) can avoid dissociating the execution of these functions and, on the other hand, the allocation unit can, if it acts independently of the compilation unit, decide not to transport the execution of these functions in a destination execution resource.
Depending on the embodiments, for developers, it is possible to provide a solution for processing the decompositions that are customisable, for example via a specific programming interface (API).
From a developer perspective, it is possible to provide the means for executing a function asynchronously with or without an ACID guarantee, with or without an order guarantee. The latter calling an end handler.
It is also possible to provide the same medium by creating a promise that will allow carrying out a simple synchronisation point in the code (f(params).then( ), or the use of “await” in higher level async functions.
To be effective, the previously-described technique shall allow transporting the execution of a large number of functions. Thanks to the technique of the inventors, every asynchronous function is potentially projectable/deportable. These may consist of:
As regards other synchronous code sequences, these are also projectable/deportable depending on their used data. For example, in a synchronous sequence, we have a following behaviour in the JavaScript code:
It is easy to understand that if A, A′, B, B′, C and C′ are different objects/properties, then FA, FB and FC are projectable/deportable and all it needs is to create a synchronisation point before Next is executed so there is no problem on execution. Thus, work on loops whose functions work on separate objects/properties is thus projectable/deportable.
Therefore, this code
May be transformed into a projectable and parallelisable sequence. Similarly, the same also applies to the function Map defined in JavaScript. let newArr=oldArr.map ((val, index, arr)=>{
A code transformation allowing creating promises for example may be used. The compilation unit generates these transformations based on the ACID property and on the execution order of the function(s). For example:
1.4. Implementation Systems and Devices
Referring to
Referring to
These means are in the form of a specific software application, or else in the form of dedicated hardware components. More particularly, in at least one embodiment, these means are in the form of several hardware components to which several software components are adjoined.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1860069 | Oct 2018 | FR | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2019/079179 | 10/25/2019 | WO |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2020/089076 | 5/7/2020 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 7665079 | Yasue | Feb 2010 | B1 |
| 8065665 | Kosche | Nov 2011 | B1 |
| 20190340012 | Granito | Nov 2019 | A1 |
| Entry |
|---|
| International Search Report dated Feb. 6, 2020 for corresponding International Application No. PCT/EP2019/079179, dated Oct. 25, 2019. |
| Written Opinion of the International Searching Authority dated Feb. 13, 2020 for corresponding International Application No. PCT/EP2019/079179, filed Oct. 25, 2019. |
| Anonymous. “javascript—WebWorkers and Asynchronous shared data access. How in Scala.js?—Stack Overflow” May 22, 2018 (May 22, 2018), Retrieved from the Internet: http://web.archive.org/web/20180522041746/https://stackoverflow.com/questions/49951842/webworkers-and-asynchronous-shared-data-access-how-in-scala-js [retrieved on Jul. 3, 2019] XP055601842. |
| Number | Date | Country | |
|---|---|---|---|
| 20210373863 A1 | Dec 2021 | US |
