CN112162840A

CN112162840A - Coroutine processing and managing method based on interrupt reentrant mechanism

Info

Publication number: CN112162840A
Application number: CN202011047310.0A
Authority: CN
Inventors: 曹蕤
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-09-29
Filing date: 2020-09-29
Publication date: 2021-01-01
Anticipated expiration: 2040-09-29
Also published as: CN112162840B

Abstract

The invention discloses a coroutine processing and managing method based on an interrupt reentry mechanism, wherein in the processing method, the coroutine comprises a main coroutine and a sub coroutine, and the interrupt reentry step comprises the following steps: s1: the master coroutine throws an interrupt request, and a bottom layer framework of the master coroutine responds to the interrupt request and asynchronously sends a task request; s2: switching to an external system processing logic, and releasing thread resources by the main coroutine; s3: the task request response executes reentry of the subprogram through a callback interface and is restored to the context state during interruption; s4: the subprogram continues to process subsequent logic until the execution is finished, and thread resources are released; or the subprogram is taken as a new main corogram to throw out an interrupt request, and the steps S1 to S4 are repeated; in the management method, the coroutines are combined into an application, and the application program entry OnProcess () comprises a CallBatch () interface in a processing method. The invention greatly reduces the complexity and workload of development and maintenance of the scheduling program with a large number of parallel branches.

Description

Coroutine processing and managing method based on interrupt reentrant mechanism

Technical Field

The invention belongs to the technical field of computers, and particularly relates to a coroutine processing and managing method based on an interrupt reentry mechanism.

Background

In business application development, some schedulers are often required to be developed, which need to advance many branch processes simultaneously, and many branch processes may need long execution time due to cooperation with the outside, such as the scheduling process shown in fig. 1 (wherein B, C, D all represent submitting a batch task and waiting for the completion result of the task). The common programming language is adopted to develop the dispatcher, the cooperation with the outside is usually realized in a synchronous blocking mode, so that the multi-branch parallel propulsion can be realized only by adopting multithreading, and the working mechanism of the dispatcher is shown in FIG. 2. Clearly, a problem with such programs is that once massive parallel pushing is required (e.g., more than 1000 parallel branches), and there are long synchronization blocked scenarios for many branches, the runtime thread resources are consumed enormously.

To solve the problem of excessive consumption of thread resources, it is common practice in the industry to program in an asynchronous callback mode, and the working mechanism is as shown in fig. 3. Obviously, the consumption of thread resources is reduced to the minimum, but the program has the problems of complex programming model, no accordance with thinking habits of people, poor maintainability of codes, even no support of componentization development, and no packaging of a Process method into a method for returning a finished result when an E action is finished.

In the newer programming languages Go, C #, developers can develop these schedulers based on the collaborative programming model, whose working mechanism is shown in fig. 4. This mechanism of operation is almost the same at the thread model level as for asynchronous callback programming: all wait actions will cause the coroutines to hang up, and the main thread will terminate after all coroutines are hung up. Upon receiving the response, the awakened coroutine will continue to be advanced in the new thread. Obviously, the program can not only minimize the consumption of thread resources, but also ensure that the programming model conforms to the thinking habit of people, the code maintainability is good, and the componentization development can be supported. Unfortunately, the languages supporting the coroutine programming model are few, and the current industry does not support the most widely used languages such as Java, C + + and the like; even if the languages support the co-programming model, most languages generally do not support the automatic high availability of programs, such as a scheduler which can be switched to run and a program which can continue to execute after the system is down.

Therefore, a coroutine processing and management method based on an interrupt reentry mechanism is urgently needed to overcome the defects in the method.

Disclosure of Invention

Aiming at the problems, the invention provides a coroutine processing and management method based on an interrupt reentry mechanism, which adopts a synchronous blocking programming model with better maintainability to develop a scheduling program with a large number of parallel branches, greatly reduces the complexity and workload of the development and maintenance of the program, can support the program to carry out componentization development and is not restricted by programming language.

In order to achieve the purpose, the invention adopts the technical scheme that:

a coroutine processing method based on an interrupt reentry mechanism is disclosed, the coroutine comprises a main coroutine and a sub coroutine, the interrupt reentry step comprises:

s1: the master coroutine throws an interrupt request, and a bottom layer framework of the master coroutine responds to the interrupt request and asynchronously sends a task request;

s2: switching to an external system processing logic, and releasing thread resources by the main coroutine;

s3: the task request response executes reentry of the subprogram through a callback interface and is restored to the context state during interruption;

s4: the subprogram continues to process subsequent logic until the execution is finished, and thread resources are released; or the subprogram serving as a new main coroutine throws an interrupt request, and the steps S1 to S4 are repeated.

Preferably, step S1 further includes, before the main coroutine first throws the interrupt request, creating an interrupt memory object and registering the interrupt memory object in a memory storage, where the memory object is used to store an execution result of the non-repeatable action, and the memory storage is used to store the context at the interrupt;

step S3 further includes, after re-entering the subroutine, executing the subroutine to the interrupted position and restoring the context to the interrupted state, and registering the response result of the task to the memory object.

More preferably, the task is a batch task, and the underlying framework of the master coroutine executes the batch task by calling a CallBatch () interface.

More preferably, the first execution of the CallBatch () interface comprises the following steps:

creating a BatchCall memory object and registering the BatchCall memory object into a memory, wherein the isInitial mark of the BatchCall memory object is true;

executing an Execute () interface of the BatchCall memory object to throw an interrupt type exception;

the caller captures the interrupt type exception and executes an executeAfterIntermission () interface of a BatchCall memory object;

the ExecuteAfterIntermission () interface calls an OnExecuteAfterIntermission () interface of the BatchCall memory object, asynchronously sends a request of a batch processing task and registers a callback interface in a memory;

after the action is executed, the isInitial mark of the BatchCall memory object is set to false, the program execution is finished, and the thread resource is released.

More preferably, the task response is switched to the main routine through the callback interface, and the method comprises the following steps:

the bottom layer framework calls a callback interface HandleResponse () by using a new thread and transmits a task response to the callback interface HandleResponse ();

the callback interface HandleResponse () invokes a Resume () interface, which invokes an OnProcess () interface to Resume execution of the host program processing logic;

when the main coroutine is executed to a CallBatch () interface again, checking the BatchCall memory object registered in the memory, wherein the isInitial of the BatchCall memory object is marked as false, no longer executing an Execute () interface, and registering a task response into the BatchCall memory object, so that the task response can be acquired from the BatchCall memory object subsequently to continue subsequent processing.

More preferably, the task response content is stored in the BatchCall memory object.

The coroutine management method based on the interrupt reentry mechanism is characterized in that the coroutine processing method based on the interrupt reentry mechanism is utilized, the coroutine is combined into an application, the coroutine comprises a coroutine identifier, an interrupt identifier (ISInterrupted) and a memory, the application operation comprises the calling of a primary starting processing interface (Process () and a multiple reentry processing interface (Resume ()), the coroutine management method further comprises an application program inlet (OnProcess ()), the starting processing interface (Process () and the reentry processing interface (Resume ()) execute processing logic by calling the application program inlet (OnProcess ()), and the application program inlet (OnProcess () comprises a CallBatch () interface; calling the application program entry OnProcess () by cycling through the coroutine set of the application before calling the application program entry OnProcess ().

Preferably, the loop traversing the coroutine set of applications comprises the steps of:

executing a while loop traversal coroutine set, setting one coroutine as a current coroutine when the coroutine is acquired through traversal, checking an interrupt identifier (ISInterrupted) of the current coroutine, and if the interrupt identifier (ISInterrupted) is true, indicating that the coroutine is in an interrupt state, and continuously traversing the next coroutine by the while loop; if the interrupt identifier is false, indicating that the interrupt is in a non-interrupt state, setting all memorized isInitial identifiers in a memory of the current coroutine as false;

calling an OnProcess () interface to execute an application processing logic, when the application executes interruption, capturing the interruption by a while loop, executing an ExecuteAfterInterruption () interface, setting an IsInterrupted identifier of the current coroutine as true, finishing the execution, and continuously traversing the next coroutine by the while loop; if the application does not throw the interruption exception from the execution of the OnProcess () interface, the current coroutine execution is finished, the while loop deletes the current coroutine from the coroutine set of the application, and the while loop continuously traverses the next coroutine;

and repeating the steps until the while loop traversal is finished.

More preferably, when the thread starts to execute for the first time through the start processing interface Process (), a default coroutine thread object whose interrupt identifier isintercepted is false is created.

More preferably, the application portal OnProcess () includes a form () interface, and the first time the form () interface is executed, the method includes the following steps:

newly generating a ForkMemory memory object, and registering the ForkMemory memory object into a memory of the current protocol, wherein the isInitial identifier of the ForkMemory memory object is true;

generating a plurality of new coroutines on the basis of a current coroutine according to the number of the introduced coroutines, wherein the new coroutines are consistent with the memory of the current coroutine, an interrupt identifier (ISI) of the new coroutine is false, and registering the new coroutines into an applied coroutine set, wherein the ForkMemory memory object stores the current coroutine and the identifiers of all newly generated coroutines;

during reentry execution, the ForkMemory object is obtained from the memory of the original protocol, at this time, the isInitial identifier of the ForkMemory object is false, the protocol is not newly created, and the application can obtain the previously generated protocol identifier from the ForkMemory object.

More preferably, the application program entry OnProcess () further includes a Merge () interface, and an application transmits the set of routine identifications generated by the Fork () interface to the Merge () interface, where the Merge () interface executes the following steps:

executing while loop traversal protocol identification set, setting one protocol identification as a current identification when the protocol identification is acquired through traversal, and if the traversed identification is the same as the identification of the current protocol, the while loop continuously traverses the next protocol identification; if the traversed identifier is different from the identifier of the current coroutine, the while loop traverses the applied coroutine set;

if the coroutines consistent with the current identification exist in the applied coroutine set, deleting the current coroutine from the coroutine set, and throwing out interruption exception;

and if no coroutine consistent with the current identification exists in the coroutine set of the application, the Merge () interface normally returns true.

Compared with the prior art, the invention has the beneficial effects that:

1. the coroutine processing and management method based on the interrupt reentrant mechanism enables a developer to develop a scheduling program with a large number of parallel branches by adopting a synchronous blocking programming model with better maintainability, greatly reduces the complexity and workload of the development and maintenance of the program, and can support the program to carry out componentized development.

2. The coroutine processing and managing method based on the interrupt reentry mechanism enables the synchronous blocking design operation of the program to be automatically converted into an asynchronous callback/non-blocking mode for execution, and ensures that the thread resource consumption is reduced to the minimum.

3. The coroutine processing and management method based on the interrupt reentry mechanism enables the program state to be automatically persisted at the thread termination moment and automatically restored when a new thread is handed over to continue execution, so that high availability characteristics such as the running of a switch, the continuous execution after the downtime restoration and the like are obtained.

4. The coroutine processing and management method based on the interrupt reentrant mechanism is not restricted by programming languages and supports C, C + +, Java and other languages.

Drawings

Fig. 1 is a schematic diagram of a scheduling process described in the background art.

Fig. 2 is a schematic diagram of a system operation mechanism described in the background art.

Fig. 3 is a schematic diagram of another system operation mechanism described in the background art.

Fig. 4 is a schematic diagram of another system operation mechanism described in the background art.

Fig. 5 is a schematic diagram of an operating mechanism of a coroutine processing method based on an interrupt reentrant mechanism according to the present invention.

Fig. 6 is a protocol case described in the second embodiment.

Fig. 7 is a coroutine case operation process described in the second embodiment.

Fig. 8 is a coroutine case operation process described in the second embodiment.

Fig. 9 is a coroutine case operation process described in the second embodiment.

Fig. 10 is a coroutine case operation process described in the second embodiment.

Fig. 11 is a schematic diagram of a working mechanism of a coroutine management method based on an interrupt reentry mechanism according to the present invention.

Fig. 12 is a schematic diagram of another working mechanism of the interrupt reentry mechanism-based coroutine management method according to the present invention.

Detailed Description

For a better understanding of the present invention, the contents of the present invention will be further explained below with reference to the drawings and examples, but the present invention is not limited to the following examples.

Example one

A coroutine processing method based on an interrupt reentry mechanism comprises a main coroutine and a sub coroutine, wherein the interrupt reentry step comprises the following steps:

s1: the master coroutine throws out an interrupt request, and a bottom layer frame of the master coroutine responds to the interrupt request and asynchronously sends a task request;

s3: the task request response executes the reentry subprogram through the callback interface and restores the reentry subprogram to the context state during interruption;

As shown in FIG. 5, the main coroutine finishes executing the PartA action to throw out the interrupt request, the underlying framework captures the interrupt and immediately executes the action and releases thread resources, then a new thread is used in the callback function to jump to the previous interrupt, and the context is restored to the state of the previous interrupt, so as to obtain the result information of the execution action of the asynchronous non-blocking interface and continue the subsequent processing. In this process, there is a repeat execution of the PartA action.

As can be seen from FIG. 5, a redo may cause the same action to be performed repeatedly, while some actions may not allow redo, such as adding an amount to an account. Therefore, in some cases, it is necessary to ensure that the nth action executed during reentry has input and output completely consistent with those of the nth action executed during reentry at a previous runtime, and does not have a new influence on the external environment (e.g., a database, a file system, environment information of the present system, environment information and data of an external system, etc.).

Therefore, step S1 further includes, before the main coroutine first throws the interrupt request, creating an interrupt memory object and registering the interrupt memory object in a memory storage, where the memory object is used to store the execution result of the non-repeatable action, and the memory storage is used to store the context at the interrupt. Step S3 further includes, after re-entering the subroutine, executing the subroutine to the interrupted position and restoring the context to the interrupted state, and registering the response result of the task in the memory object. The context here refers to all memory objects generated in this process.

Taking a batch task as an example, the underlying framework of the main coroutine executes the batch task by calling the CallBatch () interface.

The first execution of the CallBatch () interface comprises the following steps:

1. creating a BatchCall memory object and registering the BatchCall memory object into a memory, wherein the isInitial mark of the BatchCall memory object is true;

2. executing an Execute () interface of the BatchCall memory object to throw an interrupt type exception;

3. the caller captures the interrupt type exception and executes the executeAfterIntermission () interface of the BatchCall memory object;

4. the ExecuteAfterIntermission () interface calls an OnExecuteAfterIntermission () interface of a BatchCall memory object, asynchronously sends a request of a batch processing task and registers a callback interface in a memory;

5. after the action is executed, the isInitial mark of the BatchCall memory object is set to false, the program execution is finished, and the thread resource is released.

The switching of the batch processing task to the main coroutine through the callback interface comprises the following steps:

1. the bottom layer framework calls a callback interface HandleResponse () by using a new thread and transmits a task response to the callback interface HandleResponse ();

2. calling a Resume () interface by the callback interface, calling an OnProcess () interface to restart to execute the main routine processing logic by the Resume () interface;

3. when the main coroutine is executed to the CallBatch () interface again, the BatchCall memory object registered in the memory is checked, at the moment, the isInitial of the BatchCall memory object is marked as false, the Execute () interface is not executed any more, the task response is registered in the BatchCall memory object, and the task response can be acquired from the BatchCall memory object subsequently to continue the subsequent processing.

Wherein, the task response content is stored in the BatchCall memory object.

Example two

The coroutine processing method based on the interrupt reentry mechanism according to the first embodiment of the application runs the coroutine shown in fig. 6. The identifier represents a Fork action (which cannot be repeatedly executed during reentry) with a round frame starting with F, and represents a Merge action (which can be repeatedly executed during reentry) with a round frame starting with M. B. G, H shows actions that cannot be repeatedly executed during reentry, A, C, E shows actions that can be repeatedly executed during reentry, and D, F, I shows interrupt actions.

The code is realized as follows:

the complete operation process is as follows:

as shown in FIG. 7, the application initially executes based on the T1 coroutine, executing the F0 action Fork out of the T11, T12 coroutine. When the coroutine is executed based on the T11, the F1 action Fork is executed to obtain the T111 coroutine, the actions of the T1, the T11 and the T12 before the interruption are carried out, and all the actions of the T111 are completed in one thread. The actions F0 in T11, F0 in T12, and F0 and B, F1 in T111 are not repeatedly executed in the current thread and during reentry.

As shown in FIG. 8, the D-action reply is re-entered based on the T11 coroutine until the T11 coroutine terminates (or is interrupted again), noting that this process is running on a new thread. In T11, F0, B, F1 and D actions are not repeatedly executed during reentry.

As shown in FIG. 9, the F-action reply is re-entered based on the T1 coroutine until the T1 coroutine terminates (or is again interrupted). In T1, F0 and F actions are not repeatedly executed during reentry.

As shown in FIG. 10, the I-action reply is re-entered based on the T12 coroutine until the T12 coroutine terminates (or is again interrupted). In T12, the actions F0 and G, H, I are not repeatedly executed during reentry.

EXAMPLE III

As shown in fig. 11, a coroutine management method based on an interrupt reentrant mechanism, the coroutine described in the first embodiment is combined into an application, the coroutine includes a coroutine identifier, an interrupt identifier, isinterleaved, and a memory, the application runs a call including a start processing interface Process () and a reentrant processing interface result (), and further includes an application entry OnProcess (), the start processing interface Process () and the reentrant processing interface result () both execute processing logic by calling the application entry OnProcess (), and the application entry OnProcess () includes a CallBatch () interface described in the first embodiment; the application entry OnProcess () is called by looping through the application's coroutine set before calling the application entry OnProcess ().

The coroutine set of the circular traversal application comprises the following steps:

1. executing a while loop traversal coroutine set, setting one coroutine as a current coroutine when the coroutine is acquired through traversal, checking an interrupt identifier (ISInterrupted) of the current coroutine, and if the interrupt identifier (ISInterrupted) is true, indicating that the coroutine is in an interrupt state, and continuously traversing the next coroutine by the while loop; if the interrupt identifier isInterrupted is false, indicating that the interrupt is in a non-interrupt state, setting all the stored isInitial identifiers in the memory of the current coroutine to be false.

2. Calling an OnProcess () interface to execute an application processing logic, when the application executes interruption, capturing the interruption by a while loop, executing an ExecuteAfterInterruption () interface, setting an IsInterrupted identifier of the current coroutine as true, finishing the execution, and continuously traversing the next coroutine by the while loop; if the application does not throw the interruption exception from the execution of the OnProcess () interface, the current coroutine execution is finished, the while loop deletes the current coroutine from the coroutine set of the application, and the while loop continuously traverses the next coroutine. After capturing the interrupt exception, the while loop finds that the coroutine corresponding to the interrupt exception has been deleted, and then the executeaftterinterrupt () of the interrupted post-processing logic interface is not executed any more, but the next un-interrupted coroutine is continuously traversed and executed.

3. And repeating the steps until the while loop traversal is finished.

When the thread starts to execute for the first time through the start processing interface Process (), a default coroutine thread object is created, and the interrupt identifier (ISI) of the coroutine thread object is false. The application starts executing based on the coroutine.

As shown in fig. 12, the application program entry OnProcess () includes a form () interface, and by calling the form () interface provided by the underlying framework, the application can generate multiple coroutines to implement multi-branch parallel promotion. The first execution of the Fork () interface includes the following steps:

1. newly generating a ForkMemory memory object, and registering the ForkMemory memory object into a memory of the current protocol, wherein the isInitial identifier of the ForkMemory memory object is true;

2. generating a plurality of new coroutines on the basis of the current coroutines according to the number of the introduced coroutines, wherein the memories of the new coroutines are consistent with those of the current coroutines, the interrupt identifier (ISInterrupted) of the new coroutines is false, the new coroutines are registered in an applied coroutine set, and the ForkMemory memory object stores the current coroutines and the identifiers of all the newly generated coroutines;

3. during reentry execution, the ForkMemory object is obtained from the original protocol, at this time, the isInitial identifier of the ForkMemory object is false, the protocol is not newly created, and the application can obtain the previously generated protocol identifier from the ForkMemory object.

The application program inlet OnProcess () also comprises a Merge () interface, the Merge () interface is matched with the Fork () interface, and the Fork () interface transmits the generated identifications of a plurality of coroutines to the Merge () interface; the execution steps of the Merge () interface are as follows:

1. executing while loop traversal protocol identification set, setting one protocol identification as a current identification when the protocol identification is acquired through traversal, and if the traversed identification is the same as the identification of the current protocol, the while loop continuously traverses the next protocol identification; if the traversed identity is different from the identity of the current coroutine, the while loop will traverse the applied coroutine set. The Merge () interface here includes two layers of control logic inside.

2. If the coroutines consistent with the current identification exist in the applied coroutine set, the other coroutines are not executed, the current coroutine is deleted from the coroutine set, and an interruption exception is thrown out.

If the coroutine consistent with the current identification does not exist in the applied coroutine set, the while loop continues to traverse the next coroutine identification in the coroutine identification set, and the process is repeated in this way, and finally, if the identifications of other coroutines except the current coroutine in the applied coroutine set do not exist in the coroutine identification set, all the coroutines are executed, and the Merge () interface normally returns true, so that the application can continue to execute subsequent logics on the basis of the current coroutine, and the coroutine is pushed forward.

By calling the Merge () interface provided by the underlying framework, multiple coroutines of the application (all executed after the Merge point) can be 'merged' into one coroutine, thereby realizing branch pushing. When other unexecuted coroutines still exist after a certain coroutine (non-last) is executed to the Merge point, the application continues to be interrupted, meanwhile, the bottom layer framework clears the coroutine, and the last coroutine is executed to the Merge point and then continues to be processed.

Once the application runs into an interrupt (releasing thread resources), the underlying framework serializes the state of the application object into a storable format (such as XML messages, binary data …) and persists the application object into a storage device (such as a database, file …), and when an external system response comes, when a new thread is re-started, the underlying framework retrieves the persisted application state from the storage device and deserializes the persisted application state into the application object for processing.

Based on the state persistence, the application can easily realize that the machine is operated and continuously executed after the downtime is recovered, namely, when the external system responds to the load on any available system or the external system responds to the incoming after the system is crashed and recovered, a new thread can be used for reentry through a response message processing application, and then the bottom layer framework obtains the application state from the storage device and deserializes the application state into an application object to complete the subsequent processing.

Example four

The coroutine processing method based on the interruption reentry mechanism in the first embodiment and the coroutine management method based on the interruption reentry mechanism in the third embodiment are applied to process the daily batch generation salary transaction cases.

The transaction processing flow comprises 3 steps: file reading and warehousing- > generation wage- > result file generation. Where the size of the data to be processed in the file may be large (tens of thousands to millions). In order to improve the transaction processing performance on the basis of efficiently utilizing thread resources, the 3 steps are arranged in a batch generation wage scheduling application (based on scheduling system execution), in the execution of the step 2, data in a file is divided into blocks by taking 1000 batches as a unit, each block corresponds to a batch generation wage batch processing task (based on batch processing system execution), therefore, all batch processing task requests can be distributed to a batch processing system cluster in one thread by utilizing a coroutine management framework and a CallBatch interface to execute and interrupt to release thread resources, and the batch processing system can use a new thread to carry out reentry processing when responding to the arrival until the processing is completed or interrupted again.

An example of code is as follows:

it will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims

1. A coroutine processing method based on an interrupt reentry mechanism is characterized in that the coroutine comprises a main coroutine and a sub coroutine, and the interrupt reentry step comprises the following steps:

2. The coroutine processing method based on interrupt reentry mechanism of claim 1, wherein step S1 further includes, before the main coroutine first throws the interrupt request, creating an interrupt memory object and registering the interrupt memory object in a memory storage, wherein the memory object is used for storing the execution result of the non-repeatable action, and the memory storage is used for storing the interrupt context;

3. The coroutine processing method based on the interrupt reentry mechanism of claim 2, wherein the task is a batch task, and the underlying framework of the master coroutine executes the batch task by calling a CallBatch () interface.

4. The method for coroutine processing based on interrupt reentry mechanism according to claim 3, wherein the CallBatch () interface when executed for the first time comprises the following steps:

5. The method as claimed in claim 4, wherein the task response is switched to the main coroutine through a callback interface, and the method comprises the following steps:

6. The method of claim 5, wherein task response contents are stored in the memory object of BatchCall.

7. A coroutine management method based on an interrupt reentrant mechanism, characterized in that, the coroutine is combined into an application according to any one of claims 3 to 6, the coroutine includes a coroutine identifier, an interrupt identifier issirrupted and a memory, the application runs a call including a start processing interface Process () and a multiple reentry processing interface Resume (), the application also includes an application entry OnProcess (), the start processing interface Process () and the reentry processing interface Resume () both execute processing logic by calling the application entry OnProcess (), the application entry OnProcess () includes the CallBatch () interface; calling the application program entry OnProcess () by cycling through the coroutine set of the application before calling the application program entry OnProcess ().

8. The coroutine management method based on the interrupt reentry mechanism of claim 7, wherein circularly traversing the coroutine set of the application comprises the following steps:

and repeating the steps until the while loop traversal is finished.

9. The method as claimed in claim 8, wherein the thread starts executing for the first time through the start processing interface Process (), creating a default coroutine thread object whose interrupt identifier is false.

10. The coroutine management method based on interrupt reentry mechanism of claim 8, wherein the application program entry OnProcess () includes a Fork () interface, and the Fork () interface comprises the following steps when being executed for the first time:

during reentry execution, acquiring a ForkMemory memory object from a memory of an original protocol, wherein the isInitial identifier of the ForkMemory memory object is false, the protocol is not newly created, and the application can acquire a previously generated protocol identifier from the ForkMemory memory object;

preferably, the application program entry OnProcess () further includes a Merge () interface, and an application transmits the set of routine identifiers generated by the Fork () interface to the Merge () interface, where the Merge () interface executes the following steps: