CN106445692B - Network service control method and device - Google Patents

Network service control method and device Download PDF

Info

Publication number
CN106445692B
CN106445692B CN201510492414.5A CN201510492414A CN106445692B CN 106445692 B CN106445692 B CN 106445692B CN 201510492414 A CN201510492414 A CN 201510492414A CN 106445692 B CN106445692 B CN 106445692B
Authority
CN
China
Prior art keywords
service
thread
request
logic
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201510492414.5A
Other languages
Chinese (zh)
Other versions
CN106445692A (en
Inventor
何勇
张智泉
衡阵
王志坤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201510492414.5A priority Critical patent/CN106445692B/en
Publication of CN106445692A publication Critical patent/CN106445692A/en
Application granted granted Critical
Publication of CN106445692B publication Critical patent/CN106445692B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

The embodiment of the invention discloses a network service control method and a device, wherein the method comprises the following steps: sending a first service request to a service thread, and receiving a data request returned by a service logic of the first service request executed by the service thread; forwarding the data request to an I/O thread, and storing the running state of the service logic; and forwarding the service data returned by the I/O thread to the service thread, so that the service thread continues to execute the service logic from the running state. By adding the network service control mode, the service thread and the I/O thread can both maintain the technical advantages of the synchronous architecture, and the service thread does not need to wait for the I/O thread to return service data, so that the hang-up and the low performance of the server caused by the hang-up are avoided. The network service control method has the advantages of both the synchronous model and the asynchronous model, reduces the failure rate and reduces the maintenance difficulty on the premise of ensuring the stable operation of the server.

Description

Network service control method and device
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a network service control method and apparatus.
Background
Web services refer to service-oriented, distributed program-based software modules that run on a network. The framework of web services is used to implement web services.
Currently, there are some network service frameworks in the industry, which are mainly divided into two types: one is a synchronous model and one is a callback-based asynchronous model.
The execution flow of the network server architecture in the synchronization model is as follows:
1. a service thread has service data requirements in the process of processing service logic, and sends a service thread blocking request to a network I/O (Input/Output) module for requesting the service data;
2. the service thread waits for the service data returned by the network I/O module and receives the service data returned by the network I/O module;
3. and continuing to process the service logic until the service data return is finished.
However, the above synchronization model requires blocking the service thread, which may reduce the performance of the server, even cause the server to hang up, resulting in instability of the server. In order to solve the above problems, the execution flow of the callback-based asynchronous model is proposed as follows:
1. the service thread has service data requirements in the process of processing the service logic, and sends a data request to the I/O thread for requesting the service data; at this time, the service thread is not blocked;
2. the service thread immediately returns and processes other service requests;
3. service logic to process other service requests;
4. the I/O thread acquires the service data from the network I/O module after receiving the data request; when the service data of the I/O thread is prepared, calling back a notification service thread;
5. and the business thread receives the business data and continuously processes the business logic needing the business data.
However, the technical threshold of the above asynchronous model is high, and programming is complex. It is found from the actual test process that the state of the data request is difficult to maintain and often fails, and in the case of complex business logic, the I/O thread has too much callback code to cause difficult maintenance.
Disclosure of Invention
The embodiment of the invention provides a network service control method and a network service control device, which are used for providing a network service control method with the advantages of a synchronous model and an asynchronous model, reducing the failure rate and reducing the maintenance difficulty on the premise of ensuring the stable operation of a server.
A network service control method, comprising:
sending a first service request to a service thread, and receiving a data request returned by a service logic of the first service request executed by the service thread;
forwarding the data request to an I/O thread, and storing the running state of the service logic;
and forwarding the service data returned by the I/O thread to the service thread, so that the service thread continues to execute the service logic from the running state.
A network service control device, comprising:
the first sending unit is used for sending a first service request to the service thread;
a receiving unit, configured to receive a data request returned by a service logic for executing the first service request by the service thread;
a second sending unit, configured to forward the data request to an I/O thread;
the storage unit is used for storing the running state of the business logic;
the first sending unit is further configured to forward the service data returned by the I/O thread to the service thread, so that the service thread continues to execute the service logic from the running state.
Yet another aspect of the present invention provides a computer-readable storage medium having stored therein instructions, which, when executed on a computer, cause the computer to perform the method of the above-described aspects.
According to the technical scheme, the embodiment of the invention has the following advantages: by adding the network service control mode, the service thread and the I/O thread can both keep the technical advantages of the synchronous architecture, the running state of the service logic is saved, the service thread does not need to wait for the I/O thread to return service data, and therefore the hang-up and the low performance of the server caused by the hang-up are avoided. Therefore, the embodiment of the invention provides the network service control method which has the advantages of both the synchronous model and the asynchronous model, and reduces the failure rate and the maintenance difficulty on the premise of ensuring the stable operation of the server.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.
FIG. 1 is a schematic flow chart of a method according to an embodiment of the present invention;
FIG. 2 is a diagram illustrating a network service control architecture according to an embodiment of the present invention;
FIG. 3 is a schematic flow chart of a method according to an embodiment of the present invention;
FIG. 4 is a schematic structural diagram of an apparatus according to an embodiment of the present invention;
FIG. 5 is a schematic structural diagram of an apparatus according to an embodiment of the present invention;
FIG. 6 is a schematic structural diagram of an apparatus according to an embodiment of the present invention;
fig. 7 is a schematic diagram of a server structure according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention clearer, the present invention will be described in further detail with reference to the accompanying drawings, and it is apparent that the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
An embodiment of the present invention provides a network service control method, as shown in fig. 1, including:
101: sending a first service request to a service thread, and receiving a data request returned by a service logic of the first service request executed by the service thread;
a thread is a thread which executes business logic to realize business functions, is sometimes called a lightweight Process (L weight Process, L WP) and is the minimum unit of program execution flow, the thread is an entity in a Process and is a basic unit which is independently scheduled and dispatched by a system, the thread does not own system resources and only owns resources which are necessary for running at a point, but can share all the resources owned by the Process with other threads belonging to the same Process, due to mutual constraints among the threads, the thread also has three basic states of ready, blocked and running.
The business data is a data resource called by the business thread in the process of executing the business logic, and can be provided by the network I/O module side. The architecture adopted in this embodiment is obtained from a network I/O module through an I/O thread, please refer to the network service control architecture shown in fig. 2, which includes: a business thread, a network service control module, an I/O thread, and a network I/O module. The control of the embodiment is realized in a network service control module.
The terms "first" and "second" appearing in the embodiments of the present invention are used to distinguish two different technical terms of the same kind, and "first service request" and "second service request" mean two different service requests requesting service threads to execute different service logic to implement different service functions, and "first" and "second" should not be understood to have other technical meanings.
102: forwarding the data request to an I/O thread, and storing the running state of the service logic;
the data request may include information indicative of service data required by the service thread in executing the service logic, for example: identification, address or other information of the service resource that needs to be invoked. The part belongs to the data calling/acquiring part, and can be implemented by a manner known by persons skilled in the art, without affecting the implementation of the embodiment of the present invention, so the embodiment of the present invention is not limited uniquely.
The embodiment of the present invention needs to store the running state of the service logic, needs to continue to execute based on the currently executed progress of the service logic in the subsequent implementation process of the technical solution, and belongs to a control part of service logic execution, which may cause different information to be stored according to different control modes of the continued execution.
103: and forwarding the service data returned by the I/O thread to the service thread so that the service thread continues to execute the service logic from the running state.
In this embodiment, not only will the business thread be returned with the business data it requested, but also the business thread will be controlled to continue executing from the progress that the business logic was in when the data request was previously returned.
According to the embodiment of the invention, by adding a network service control mode, the service thread and the I/O thread can both keep the technical advantages of a synchronous framework, the running state of the service logic is saved, and the service thread does not need to wait for the I/O thread to return service data, so that the hang-up and the low performance of the server caused by the hang-up are avoided. Therefore, the embodiment of the invention provides the network service control method which has the advantages of both the synchronous model and the asynchronous model, and reduces the failure rate and the maintenance difficulty on the premise of ensuring the stable operation of the server.
In the embodiment of the present invention, there may be a service data requirement in the execution process of the service logic of the first service request, at this time, the execution main body controlled by the network service stores the running state of the service logic of the first service request, and the service thread is in an idle state after that, in this case, the service thread may process other service requests, so the embodiment of the present invention provides the following solution: after receiving a data request returned by the service thread executing the service logic of the first service request, the method further includes:
and sending a second service request to the service thread.
In this embodiment, after the second service request is sent to the service thread, the service thread will start to execute the service logic corresponding to the second service request. At the time when the "business thread continues to execute the business logic from the running state" needs to be implemented, the business logic of the second business request may have been executed or may be in the process of being executed. If the execution is finished, the business thread is in an idle state, and the situation is simple and will not be described. If the service logic of the second service request is still in the process of executing, there may be the following three options: firstly, sending an interrupt request to a service thread, then controlling the service thread to continue to execute the service logic from the running state, and then continuing to execute the service logic corresponding to the second service request; and secondly, sending the running state of the business logic of the first business request to the business thread in the idle state, and enabling the business thread in the idle state to continuously execute the business logic from the running state. Here, the service thread in the idle state may be another idle service thread which is found by having a plurality of service threads and inquiring after the service thread of the service logic executing the second service request is executed.
The embodiment of the present invention further provides an optional main body selection for executing the embodiment of the present invention, which is specifically as follows: the sending the first service request to the service thread includes:
the finite state machine sends a first service request to the service thread.
It should be noted that a finite state machine may be used as an alternative to a specific implementation scheme for implementing the functions of the embodiment of the present invention, and in practical applications, only technical functional components capable of implementing the above functions are required, so the finite state machine should not be construed as the only limitation to the embodiment of the present invention. A Finite-state machine (FSM), also called Finite-state automata, abbreviated as state machine, is a mathematical model representing Finite states and the behaviors of transitions and actions between the states. In digital circuitry, a finite state machine is a sequential logic circuit block.
The embodiment of the present invention further provides a more specific implementation scheme example based on a finite-state machine, which is specifically as follows: the finite state machine includes: coordinating the program.
Coroutine (coroutine) is not a process or thread, which performs more like a subroutine, or a function call without a return value. Coroutines are also a program component. A program may contain multiple coroutines, which may correspond to multiple threads contained by a process. The multiple threads are relatively independent, have own contexts, and the switching is controlled by the system; the coroutines are relatively independent and have own contexts, but the switching is controlled by the coroutines, and the current coroutines are switched to other coroutines and controlled by the current coroutines.
The embodiment of the invention also provides a specific implementation scheme for receiving the service data from the I/O thread, which comprises the following steps: before forwarding the data request to an I/O thread, the method further includes:
and receiving the service data returned by the I/O thread through the callback.
It can be understood that the service data sent from the I/O thread to the execution agent of the network service control may be actively sent or passively sent; the callback may be called or transferred in a shared memory space, and therefore the callback should not be construed as a unique limitation to the embodiment of the present invention.
The embodiment of the present invention further provides a specific implementation example for enabling the service thread to continue executing the service logic from the running state, which is specifically as follows: the forwarding the service data returned by the I/O thread to the service thread so that the service thread continues to execute the service logic from the running state includes:
and sending the service data returned by the I/O thread and the stored running state of the service logic to the service thread, and indicating the service thread to continue to execute the service logic from the running state.
The following embodiments will describe the embodiments of the present invention in the context of a system architecture, in which the implementation of network service control is implemented by coroutines, as shown in fig. 3:
301: the coroutine delivers the service request to a service thread, and the service thread is requested to process the service logic of the service request;
302: the business thread has business data requirements in the process of processing the business logic of the business request, sends a data request to the coroutine, and requests to return corresponding business data; the coroutine forwards the data request to an I/O thread, and the I/O thread obtains service data from a network I/O module;
303: the coroutine saves the relevant information of the operation state of the business logic corresponding to the business request;
304: the coroutine delivers a new service request to the service thread, and the new service request is executed by the service thread;
305: service data returned by the I/O thread is obtained through callback, at the moment, the service data can be interacted with the service thread, and the running state of the stored service logic can be sent to the service thread;
306: and the business thread continues to execute the business logic from the running state of the business logic.
By combining the advantages of a pure synchronous model and a callback-based asynchronous model, development threshold is low for common developers, the synchronous coding realizes business services, the business requirement development can be easily completed, and the developed services have asynchronous operation capability and greatly improve the performance of service processing.
An embodiment of the present invention further provides a network service control apparatus, as shown in fig. 4, including:
a first sending unit 401, configured to send a first service request to a service thread;
a receiving unit 402, configured to receive a data request returned by a service logic of the service thread executing the first service request;
a second sending unit 403, configured to forward the data request to an I/O thread;
a saving unit 404, configured to save an operating state of the service logic;
the first sending unit 401 is further configured to forward the service data returned by the I/O thread to the service thread, so that the service thread continues to execute the service logic from the running state.
A thread is a thread which executes business logic to realize business functions, is sometimes called a lightweight Process (L weight Process, L WP) and is the minimum unit of program execution flow, the thread is an entity in a Process and is a basic unit which is independently scheduled and dispatched by a system, the thread does not own system resources and only owns resources which are necessary for running at a point, but can share all the resources owned by the Process with other threads belonging to the same Process, due to mutual constraints among the threads, the thread also has three basic states of ready, blocked and running.
The business data is a data resource called by the business thread in the process of executing the business logic, and can be provided by the network I/O module side. The architecture adopted in this embodiment is obtained from a network I/O module through an I/O thread, please refer to the network service control architecture shown in fig. 2, which includes: a business thread, a network service control module, an I/O thread, and a network I/O module. The control of the embodiment is realized in a network service control module.
The terms "first" and "second" appearing in the embodiments of the present invention are used to distinguish two different technical terms of the same kind, and "first service request" and "second service request" mean two different service requests requesting service threads to execute different service logic to implement different service functions, and "first" and "second" should not be understood to have other technical meanings.
The data request may include information indicative of service data required by the service thread in executing the service logic, for example: identification, address or other information of the service resource that needs to be invoked. The part belongs to the data calling/acquiring part, and can be implemented by a manner known by persons skilled in the art, without affecting the implementation of the embodiment of the present invention, so the embodiment of the present invention is not limited uniquely.
The embodiment of the present invention needs to store the running state of the service logic, needs to continue to execute based on the currently executed progress of the service logic in the subsequent implementation process of the technical solution, and belongs to a control part of service logic execution, which may cause different information to be stored according to different control modes of the continued execution.
In this embodiment, not only will the business thread be returned with the business data it requested, but also the business thread will be controlled to continue executing from the progress that the business logic was in when the data request was previously returned.
According to the embodiment of the invention, by adding a network service control mode, the service thread and the I/O thread can both keep the technical advantages of a synchronous framework, the running state of the service logic is saved, and the service thread does not need to wait for the I/O thread to return service data, so that the hang-up and the low performance of the server caused by the hang-up are avoided. Therefore, the embodiment of the invention provides the network service control method which has the advantages of both the synchronous model and the asynchronous model, and reduces the failure rate and the maintenance difficulty on the premise of ensuring the stable operation of the server.
In the embodiment of the present invention, there may be a service data requirement in the execution process of the service logic of the first service request, at this time, the execution main body controlled by the network service stores the running state of the service logic of the first service request, and the service thread is in an idle state after that, in this case, the service thread may process other service requests, so the embodiment of the present invention provides the following solution: further, the first sending unit 401 is further configured to send a second service request to the service thread after the receiving unit 402 receives a data request returned by the service thread executing the service logic of the first service request.
In this embodiment, after the second service request is sent to the service thread, the service thread will start to execute the service logic corresponding to the second service request. At the time when the "business thread continues to execute the business logic from the running state" needs to be implemented, the business logic of the second business request may have been executed or may be in the process of being executed. If the execution is finished, the business thread is in an idle state, and the situation is simple and will not be described. If the service logic of the second service request is still in the process of executing, there may be the following three options: firstly, sending an interrupt request to a service thread, then controlling the service thread to continue to execute the service logic from the running state, and then continuing to execute the service logic corresponding to the second service request; and secondly, sending the running state of the business logic of the first business request to the business thread in the idle state, and enabling the business thread in the idle state to continuously execute the business logic from the running state. Here, the service thread in the idle state may be another idle service thread which is found by having a plurality of service threads and inquiring after the service thread of the service logic executing the second service request is executed.
The embodiment of the present invention further provides an optional main body selection for executing the embodiment of the present invention, which is specifically as follows: optionally, the first sending unit 401 is specifically configured to send the first service request to the service thread by using a finite state machine.
It should be noted that a finite state machine may be used as an alternative to a specific implementation scheme for implementing the functions of the embodiment of the present invention, and in practical applications, only technical functional components capable of implementing the above functions are required, so the finite state machine should not be construed as the only limitation to the embodiment of the present invention. A Finite-state machine (FSM), also called Finite-state automata, abbreviated as state machine, is a mathematical model representing Finite states and the behaviors of transitions and actions between the states. In digital circuitry, a finite state machine is a sequential logic circuit block.
The embodiment of the present invention further provides a more specific implementation scheme example based on a finite-state machine, which is specifically as follows: the finite state machine includes: coordinating the program.
Coroutine (coroutine) is not a process or thread, which performs more like a subroutine, or a function call without a return value. Coroutines are also a program component. A program may contain multiple coroutines, which may correspond to multiple threads contained by a process. The multiple threads are relatively independent, have own contexts, and the switching is controlled by the system; the coroutines are relatively independent and have own contexts, but the switching is controlled by the coroutines, and the current coroutines are switched to other coroutines and controlled by the current coroutines.
The embodiment of the invention also provides a specific implementation scheme for receiving the service data from the I/O thread, which comprises the following steps: the receiving unit 402 is further configured to receive, through a callback, service data returned by the I/O thread before the first sending unit 401 forwards the data request to the I/O thread.
It can be understood that the service data sent from the I/O thread to the execution agent of the network service control may be actively sent or passively sent; the callback may be called or transferred in a shared memory space, and therefore the callback should not be construed as a unique limitation to the embodiment of the present invention.
The embodiment of the present invention further provides a specific implementation example for enabling the service thread to continue executing the service logic from the running state, which is specifically as follows: the first sending unit 401 is configured to send the service data returned by the I/O thread and the saved running state of the service logic to the service thread, and instruct the service thread to continue executing the service logic from the running state.
An embodiment of the present invention further provides another network service control apparatus, as shown in fig. 5, including: an input port 501, an output port 502, a processor 503, and a memory 504;
wherein, the processor 503 is configured to control and execute: sending a first service request to a service thread, and receiving a data request returned by a service logic of the first service request executed by the service thread; forwarding the data request to an I/O thread, and storing the running state of the service logic; and forwarding the service data returned by the I/O thread to the service thread so that the service thread continues to execute the service logic from the running state.
The business data is a data resource called by the business thread in the process of executing the business logic, and can be provided by the network I/O module side. The architecture adopted in this embodiment is obtained from a network I/O module through an I/O thread, please refer to the network service control architecture shown in fig. 2, which includes: a business thread, a network service control module, an I/O thread, and a network I/O module. The control of the embodiment is realized in a network service control module.
The terms "first" and "second" appearing in the embodiments of the present invention are used to distinguish two different technical terms of the same kind, and "first service request" and "second service request" mean two different service requests requesting service threads to execute different service logic to implement different service functions, and "first" and "second" should not be understood to have other technical meanings.
The data request may include information indicative of service data required by the service thread in executing the service logic, for example: identification, address or other information of the service resource that needs to be invoked. The part belongs to the data calling/acquiring part, and can be implemented by a manner known by persons skilled in the art, without affecting the implementation of the embodiment of the present invention, so the embodiment of the present invention is not limited uniquely.
The embodiment of the present invention needs to store the running state of the service logic, needs to continue to execute based on the currently executed progress of the service logic in the subsequent implementation process of the technical solution, and belongs to a control part of service logic execution, which may cause different information to be stored according to different control modes of the continued execution.
In this embodiment, not only will the business thread be returned with the business data it requested, but also the business thread will be controlled to continue executing from the progress that the business logic was in when the data request was previously returned.
According to the embodiment of the invention, by adding a network service control mode, the service thread and the I/O thread can both keep the technical advantages of a synchronous framework, the running state of the service logic is saved, and the service thread does not need to wait for the I/O thread to return service data, so that the hang-up and the low performance of the server caused by the hang-up are avoided. Therefore, the embodiment of the invention provides the network service control method which has the advantages of both the synchronous model and the asynchronous model, and reduces the failure rate and the maintenance difficulty on the premise of ensuring the stable operation of the server.
In the embodiment of the present invention, there may be a service data requirement in the execution process of the service logic of the first service request, at this time, the execution main body controlled by the network service stores the running state of the service logic of the first service request, and the service thread is in an idle state after that, in this case, the service thread may process other service requests, so the embodiment of the present invention provides the following solution:
the processor 503 is further configured to control and execute: and after receiving a data request returned by the business logic of the first business request executed by the business thread, sending a second business request to the business thread.
In this embodiment, after the second service request is sent to the service thread, the service thread will start to execute the service logic corresponding to the second service request. At the time when the "business thread continues to execute the business logic from the running state" needs to be implemented, the business logic of the second business request may have been executed or may be in the process of being executed. If the execution is finished, the business thread is in an idle state, and the situation is simple and will not be described. If the service logic of the second service request is still in the process of executing, there may be the following three options: firstly, sending an interrupt request to a service thread, then controlling the service thread to continue to execute the service logic from the running state, and then continuing to execute the service logic corresponding to the second service request; and secondly, sending the running state of the business logic of the first business request to the business thread in the idle state, and enabling the business thread in the idle state to continuously execute the business logic from the running state. Here, the service thread in the idle state may be another idle service thread which is found by having a plurality of service threads and inquiring after the service thread of the service logic executing the second service request is executed.
The embodiment of the present invention further provides an optional main body selection for executing the embodiment of the present invention, which is specifically as follows: the processor 503 is further configured to control and execute: sending the first service request to the service thread includes: a first service request is sent to a service thread through a finite state machine.
It should be noted that a finite state machine may be used as an alternative to a specific implementation scheme for implementing the functions of the embodiment of the present invention, and in practical applications, only technical functional components capable of implementing the above functions are required, so the finite state machine should not be construed as the only limitation to the embodiment of the present invention. A Finite-state machine (FSM), also called Finite-state automata, abbreviated as state machine, is a mathematical model representing Finite states and the behaviors of transitions and actions between the states. In digital circuitry, a finite state machine is a sequential logic circuit block.
The embodiment of the present invention further provides a more specific implementation scheme example based on a finite-state machine, which is specifically as follows: the finite state machine includes: coordinating the program.
Coroutine (coroutine) is not a process or thread, which performs more like a subroutine, or a function call without a return value. Coroutines are also a program component. A program may contain multiple coroutines, which may correspond to multiple threads contained by a process. The multiple threads are relatively independent, have own contexts, and the switching is controlled by the system; the coroutines are relatively independent and have own contexts, but the switching is controlled by the coroutines, and the current coroutines are switched to other coroutines and controlled by the current coroutines.
The embodiment of the invention also provides a specific implementation scheme for receiving the service data from the I/O thread, which comprises the following steps: the processor 503 is further configured to control and execute: and before forwarding the data request to the I/O thread, receiving the service data returned by the I/O thread through a callback.
It can be understood that the service data sent from the I/O thread to the execution agent of the network service control may be actively sent or passively sent; the callback may be called or transferred in a shared memory space, and therefore the callback should not be construed as a unique limitation to the embodiment of the present invention.
The embodiment of the present invention further provides a specific implementation example for enabling the service thread to continue executing the service logic from the running state, which is specifically as follows: the processor 503 is configured to control and execute: forwarding the service data returned by the I/O thread to the service thread, so that the service thread continues to execute the service logic from the running state includes:
and sending the service data returned by the I/O thread and the stored running state of the service logic to the service thread, and indicating the service thread to continue to execute the service logic from the running state.
As shown in fig. 6, for convenience of description, only the parts related to the embodiment of the present invention are shown, and details of the specific technology are not disclosed, please refer to the method part of the embodiment of the present invention. The device may be any terminal device including a mobile phone, a tablet computer, a PDA (Personal Digital Assistant), a POS (Point of Sales), a vehicle-mounted computer, etc., taking the terminal as the mobile phone as an example:
fig. 6 is a block diagram illustrating a partial structure of a mobile phone related to a terminal provided in an embodiment of the present invention. Referring to fig. 6, the handset includes: radio Frequency (RF) circuit 610, memory 620, input unit 630, display unit 640, sensor 650, audio circuit 660, wireless fidelity (WiFi) module 670, processor 680, and power supply 690. Those skilled in the art will appreciate that the handset configuration shown in fig. 6 is not intended to be limiting and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.
The following describes each component of the mobile phone in detail with reference to fig. 6:
the RF circuit 610 may be used for receiving and transmitting signals during a message transmission or call, and in particular, for receiving downlink information of a base station and processing the received downlink information to the processor 680 and transmitting data for a design uplink to the base station, generally, the RF circuit 610 includes, but is not limited to, an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (L w noise amplifier, &ltttttransmission = L "&gttl &ttt/t &gtna), a duplexer, etc. furthermore, the RF circuit 610 may also communicate with a network and other devices through wireless communication, which may use any communication standard or protocol, including, but not limited to, a global system for Mobile communication (GSM), a General Packet radio Service (General Packet radio Service, GPRS), a Code Division Multiple Access (Wideband Code Division Multiple Access, CDMA), a CDMA (Wireless Access, Wireless Service (SMS), SMS L), and the like.
The memory 620 may be used to store software programs and modules, and the processor 680 may execute various functional applications and data processing of the mobile phone by operating the software programs and modules stored in the memory 620. The memory 620 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data (such as audio data, a phonebook, etc.) created according to the use of the cellular phone, and the like. Further, the memory 620 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device.
The input unit 630 may be used to receive input numeric or character information and generate key signal inputs related to user settings and function control of the cellular phone. Specifically, the input unit 630 may include a touch panel 631 and other input devices 632. The touch panel 631, also referred to as a touch screen, may collect touch operations of a user (e.g., operations of the user on the touch panel 631 or near the touch panel 631 by using any suitable object or accessory such as a finger or a stylus) thereon or nearby, and drive the corresponding connection device according to a preset program. Alternatively, the touch panel 631 may include two parts of a touch detection device and a touch controller. The touch detection device detects the touch direction of a user, detects a signal brought by touch operation and transmits the signal to the touch controller; the touch controller receives touch information from the touch sensing device, converts the touch information into touch point coordinates, sends the touch point coordinates to the processor 680, and can receive and execute commands sent by the processor 680. In addition, the touch panel 631 may be implemented using various types, such as resistive, capacitive, infrared, and surface acoustic wave. The input unit 630 may include other input devices 632 in addition to the touch panel 631. In particular, other input devices 632 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.
The display unit 640 may include a display panel 641, and optionally, the display panel 641 may be configured in the form of a liquid crystal display (L acquired crystal display, &ttttranslation = L "&gtt L &ttt/t &gttcd), an Organic light Emitting Diode (Organic L sight-Emitting Diode, O L ED), or the like, and further, the touch panel 631 may cover the display panel 641, and when the touch panel 631 detects a touch operation on or near the touch panel 631, the touch panel 680 may be transferred to the processor 680 to determine the type of touch event, and then the processor 680 may provide a corresponding visual output on the display panel according to the type of touch event.
The handset may also include at least one sensor 650, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor that adjusts the brightness of the display panel 641 according to the brightness of ambient light, and a proximity sensor that turns off the display panel 641 and/or the backlight when the mobile phone is moved to the ear. As one of the motion sensors, the accelerometer sensor can detect the magnitude of acceleration in each direction (generally, three axes), can detect the magnitude and direction of gravity when stationary, and can be used for applications of recognizing the posture of a mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer and tapping), and the like; as for other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, and an infrared sensor, which can be configured on the mobile phone, further description is omitted here.
Audio circuit 660, speaker 661, and microphone 662 can provide an audio interface between a user and a cell phone. The audio circuit 660 may transmit the electrical signal converted from the received audio data to the speaker 661, and convert the electrical signal into an audio signal through the speaker 661 for output; on the other hand, the microphone 662 converts the collected sound signals into electrical signals, which are received by the audio circuit 660 and converted into audio data, which are processed by the audio data output processor 680 and then transmitted via the RF circuit 610 to, for example, another cellular phone, or output to the memory 620 for further processing.
WiFi belongs to short-distance wireless transmission technology, and the mobile phone can help a user to receive and send e-mails, browse webpages, access streaming media and the like through the WiFi module 670, and provides wireless broadband Internet access for the user. Although fig. 6 shows the WiFi module 670, it is understood that it does not belong to the essential constitution of the handset, and can be omitted entirely as needed within the scope not changing the essence of the invention.
The processor 680 is a control center of the mobile phone, and connects various parts of the entire mobile phone by using various interfaces and lines, and performs various functions of the mobile phone and processes data by operating or executing software programs and/or modules stored in the memory 620 and calling data stored in the memory 620, thereby performing overall monitoring of the mobile phone. Optionally, processor 680 may include one or more processing units; preferably, the processor 680 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into processor 680.
The handset also includes a power supply 690 (e.g., a battery) for powering the various components, which may preferably be logically connected to the processor 680 via a power management system, such that the power management system may be used to manage charging, discharging, and power consumption.
Although not shown, the mobile phone may further include a camera, a bluetooth module, etc., which are not described herein.
In the embodiment of the present invention, the processor 680 included in the terminal further has the following functions:
fig. 7 is a schematic diagram of a server structure provided by an embodiment of the present invention, where the server 700 may have a relatively large difference due to different configurations or performances, and may include one or more Central Processing Units (CPUs) 722 (e.g., one or more processors) and a memory 732, and one or more storage media 730 (e.g., one or more mass storage devices) for storing applications 742 or data 744. Memory 732 and storage medium 730 may be, among other things, transient storage or persistent storage. The program stored in the storage medium 730 may include one or more modules (not shown), each of which may include a series of instruction operations for the server. Further, the central processor 722 may be configured to communicate with the storage medium 730, and execute a series of instruction operations in the storage medium 730 on the server 700.
The server 700 may also include one or more power supplies 726, one or more wired or wireless network interfaces 750, one or more input-output interfaces 758, and/or one or more operating systems 741, such as Windows ServerTM, Mac OS XTM, UnixTM, and &lTtTtranslation = L "&gTtL &lTt/T &gTtinxTM, FreeDTM, and so forth.
The steps performed by the network server control means in the above-described embodiment may be based on the server configuration shown in fig. 7.
It should be noted that, in the above device embodiment, each included unit is only divided according to functional logic, but is not limited to the above division as long as the corresponding function can be achieved; in addition, specific names of the functional units are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present invention.
In addition, it is understood by those skilled in the art that all or part of the steps in the above method embodiments may be implemented by related hardware, and the corresponding program may be stored in a computer readable storage medium, where the above mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk.
The above description is only for the preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the embodiment of the present invention are included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims (10)

1. A network service control method is applied to a network service control module, and the method comprises the following steps:
sending a first service request to a service thread, and receiving a data request returned by a service logic of the first service request executed by the service thread;
forwarding the data request to an I/O thread, and storing the running state of the service logic of the first service request;
forwarding the service data returned by the I/O thread and the stored running state of the service logic of the first service request to the service thread, so that the service thread continues to execute the service logic of the first service request from the running state;
after receiving a data request returned by the service logic of the service thread executing the first service request, the method further comprises:
sending a second service request to the service thread;
when a service thread continues to execute the service logic of a first service request from a running state, if the service logic of a second service request is still in the execution process, sending an interrupt request to the service thread, and controlling the service thread to continue to execute the service logic of the first service request from the running state and then continue to execute the service logic corresponding to the second service request.
2. The method of claim 1, wherein sending the first service request to the service thread comprises:
the finite state machine sends a first service request to the service thread.
3. The method of claim 2, wherein the finite state machine comprises: coordinating the program.
4. The method of any of claims 1 to 3, wherein prior to forwarding the data request to an I/O thread, the method further comprises:
and receiving the service data returned by the I/O thread through the callback.
5. A network service control apparatus, the apparatus being applied to a network service control module, the apparatus comprising:
the first sending unit is used for sending a first service request to the service thread;
a receiving unit, configured to receive a data request returned by a service logic for executing the first service request by the service thread;
a second sending unit, configured to forward the data request to an I/O thread;
a storage unit, configured to store an operation state of the service logic of the first service request;
the first sending unit is further configured to forward the service data returned by the I/O thread and the stored running state of the service logic of the first service request to the service thread, so that the service thread continues to execute the service logic of the first service request from the running state;
the first sending unit is further configured to send a second service request to the service thread after the receiving unit receives a data request returned by the service logic of the service thread executing the first service request; when a service thread continues to execute the service logic of a first service request from a running state, if the service logic of a second service request is still in the execution process, sending an interrupt request to the service thread, and controlling the service thread to continue to execute the service logic of the first service request from the running state and then continue to execute the service logic corresponding to the second service request.
6. The apparatus of claim 5,
the first sending unit is specifically configured to send a first service request to a service thread by using a finite state machine.
7. The apparatus of claim 6, wherein the finite state machine comprises: coordinating the program.
8. The apparatus according to any one of claims 5 to 7,
the receiving unit is further configured to receive, through a callback, service data returned by the I/O thread before the first sending unit forwards the data request to the I/O thread.
9. A network service control apparatus, comprising:
a processor and a memory;
the processor is used for calling and executing the program stored in the memory;
the memory is configured to store the program, the program at least to: implementing the network service control method according to any of the preceding claims 1 to 4.
10. A computer-readable storage medium comprising instructions that, when executed on a computer, cause the computer to perform the method of any of claims 1-4.
CN201510492414.5A 2015-08-12 2015-08-12 Network service control method and device Active CN106445692B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510492414.5A CN106445692B (en) 2015-08-12 2015-08-12 Network service control method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510492414.5A CN106445692B (en) 2015-08-12 2015-08-12 Network service control method and device

Publications (2)

Publication Number Publication Date
CN106445692A CN106445692A (en) 2017-02-22
CN106445692B true CN106445692B (en) 2020-07-24

Family

ID=58093399

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510492414.5A Active CN106445692B (en) 2015-08-12 2015-08-12 Network service control method and device

Country Status (1)

Country Link
CN (1) CN106445692B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110825455A (en) * 2019-10-31 2020-02-21 郑州悉知信息科技股份有限公司 Application program running method, device and system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101262498A (en) * 2008-04-22 2008-09-10 华为技术有限公司 A distributed message call method and device
CN102567111A (en) * 2011-12-23 2012-07-11 深圳市融创天下科技股份有限公司 Method, system and terminal device capable of calling asynchronous procedure
CN103019806A (en) * 2011-09-22 2013-04-03 北京新媒传信科技有限公司 Asynchronous task processing method and device
CN103970592A (en) * 2013-01-25 2014-08-06 深圳市金证科技股份有限公司 Single-thread multi-task processing method and server of transaction middleware

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8756604B2 (en) * 2011-12-13 2014-06-17 Microsoft Corporation Async wrapper handling execution of asynchronous operations for synchronous and asynchronous routines

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101262498A (en) * 2008-04-22 2008-09-10 华为技术有限公司 A distributed message call method and device
CN103019806A (en) * 2011-09-22 2013-04-03 北京新媒传信科技有限公司 Asynchronous task processing method and device
CN102567111A (en) * 2011-12-23 2012-07-11 深圳市融创天下科技股份有限公司 Method, system and terminal device capable of calling asynchronous procedure
CN103970592A (en) * 2013-01-25 2014-08-06 深圳市金证科技股份有限公司 Single-thread multi-task processing method and server of transaction middleware

Also Published As

Publication number Publication date
CN106445692A (en) 2017-02-22

Similar Documents

Publication Publication Date Title
WO2017206916A1 (en) Method for determining kernel running configuration in processor and related product
EP3525417A1 (en) Data processing method, device, storage medium, electronic device and server
CN107786424B (en) Audio and video communication method, terminal and server
WO2017206915A1 (en) Method for determining kernel running configuration in processor and related product
WO2014206138A1 (en) Webpage data update method, apparatus and terminal device
CN107193551B (en) Method and device for generating image frame
CN111026457B (en) Hardware configuration method and device, storage medium and terminal equipment
CN109947617B (en) Method, terminal and readable storage medium for monitoring display content of application interface
CN109743469B (en) VOLTE-based communication method and mobile terminal
CN106445692B (en) Network service control method and device
CN105528220B (en) Method and device for loading dynamic shared object
CN111045737A (en) Equipment identifier acquisition method and device, terminal equipment and storage medium
CN106209601B (en) State update message pushing method and device
CN110995324B (en) Bluetooth communication method, device, storage medium and terminal equipment
CN112261634B (en) Bluetooth transmission control method and device, terminal equipment and storage medium
CN108280798B (en) Method and device for rendering and displaying browser kernel
CN110618798A (en) Multi-screen display method, multi-screen device, storage medium and terminal equipment
CN111885591A (en) Network connection method, device, storage medium and terminal
CN112399405A (en) Method and device for reporting user equipment capability information and mobile terminal
CN111083285A (en) Mobile terminal call positioning system and method
CN108111553B (en) Method and device for providing service
CN110913022A (en) Method, device and system for downloading network file of mobile terminal and storage medium
CN105279175B (en) Data transmission method and device
CN105278967B (en) System updating method, device and system of mobile terminal
CN114189436B (en) Multi-cluster configuration deployment method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant