Background service process adjusting method, optical ranging system and related equipment

Abstract

The embodiment of the invention provides an adjustment method of a background service process, an optical ranging system and related equipment, and is used for solving the problem that the background service process cannot be dynamically debugged or controlled in a running process. The method comprises the steps that when an application program is started, a signal processing callback function is registered for a first user-defined signal and a second user-defined signal; receiving at least one first user-defined signal and at least one second user-defined signal sent by the outside, and counting the first signal frequency of the received first user-defined signal and the second signal frequency of the received second user-defined signal in a preset time window; generating a function request code according to the first signal frequency and the second signal frequency; and calling the signal processing callback function to execute corresponding backdoor operation according to the function request code and a predefined function mapping table.

Description

Technical Field

[0001] This application relates to the field of software debugging, and more particularly to a method for adjusting a background service process, an optical ranging system, and related equipment. Background Technology

[0002] With the increasing prevalence of Linux operating systems in various devices, the debugging and behavior control of background service processes (such as daemons), which serve as the core functionalities of the system, has become a key challenge in development and maintenance. In embedded scenarios such as optical ranging, systems often run as background services without an interactive interface, making on-site debugging difficult once deployed. Traditional debugging methods, such as log output, environment variable or command-line parameter adjustments, have significant limitations: logs can only passively record information and cannot actively trigger behavior; environment variables and command-line parameters must be set before the process starts and cannot be dynamically modified at runtime. Especially for background services that are already running, existing technologies lack a lightweight, non-intrusive mechanism that can achieve dynamic behavior control and status query without restarting the process.

[0003] Although the Linux kernel provides virtual file system interfaces such as debugfs and sysfs for driver debugging, user-space background service processes lack similar standardized debugging control channels. While external control can be achieved through inter-process communication, network sockets, or pipes, these solutions often introduce additional complexity, resource overhead, or security risks, making them unsuitable for resource-constrained or real-time-critical embedded environments. Summary of the Invention

[0004] This application provides a method and related equipment for adjusting background service processes, which solves the problem that the behavior of background service processes cannot be dynamically debugged or controlled during operation.

[0005] The first aspect of this application provides a method for adjusting a background service process, including:

[0006] When the application starts, register signal handling callback functions for the first user-defined signal and the second user-defined signal;

[0007] Receive at least one first user-defined signal and one second user-defined signal sent from outside, and within a preset time window, count the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal received;

[0008] Generate a function request code based on the number of the first signal and the number of the second signal;

[0009] Based on the function request code and the predefined function mapping table, the signal processing callback function is called to execute the corresponding backdoor operation.

[0010] Optionally, generating the function request code based on the first signal count and the second signal count includes:

[0011] Input the first signal count and the second signal count into the function request code calculation formula to calculate and obtain the function request code; wherein, the function request code calculation formula is: The The function request code, the For the first signal number, the The number of times the second signal is received.

[0012] Optionally, the method further includes:

[0013] Design external control scripts;

[0014] According to the external control script, the function request code and target process identifier input by the user are received;

[0015] Based on the function request code, calculate the number of times the first user-defined signal and the second user-defined signal need to be sent, and send the first user-defined signal and the second user-defined signal to the target process in a predetermined sending order and at a sending interval.

[0016] Optionally, the step of counting the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal within a preset time window includes:

[0017] The timer is started when the first user-defined signal or the second user-defined signal is received for the first time.

[0018] Within the time window set by the timer, the cumulative number of times the first user-defined signal and the second user-defined signal are received is calculated.

[0019] When the timer expires, the function request code is generated based on the cumulative number of receptions, and the backdoor operation is triggered; wherein, the cumulative number of receptions includes the number of receptions of the first user-defined signal and the number of receptions of the second user-defined signal.

[0020] Optionally, the method further includes:

[0021] During the processing time period when a feature request code is being processed, the first user-defined signal and the second user-defined signal received during the processing time period are ignored.

[0022] Optionally, after performing the corresponding backdoor operation, the method further includes:

[0023] Reset the counter variable and status flags used to count the number of user-defined signals in preparation for responding to the next user's feature request.

[0024] Optionally,

[0025] The predefined function mapping table is used to map different function request codes to different signal processing callback functions to complete function calls, including at least one of the following: a status information output function for debugging, a debug log level switching function, a data capture function, or an algorithm module switch control function;

[0026] The backdoor operation includes at least one of outputting internal status, switching operating modes, modifying configuration parameters, or executing debugging functions.

[0027] A second aspect of this application provides a system for adjusting background service processes, including:

[0028] The registration unit is used to register signal handling callback functions for the first user-defined signal and the second user-defined signal when the application starts.

[0029] The receiving unit is configured to receive at least one first user-defined signal and one second user-defined signal transmitted from outside, and within a preset time window, count the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal received;

[0030] The generation unit is configured to generate a function request code based on the number of the first signal and the number of the second signal;

[0031] The calling unit is used to call the signal processing callback function to execute the corresponding backdoor operation based on the function request code and the predefined function mapping table.

[0032] The background service process adjustment system provided in the second aspect of this application is used to execute the background service process adjustment method described in the first aspect.

[0033] A third aspect of this application provides an optical ranging system, including: an optical ranging module, a signal processing module, and a control script module;

[0034] The optical ranging module is used to perform distance measurement tasks;

[0035] The signal processing module is integrated into the background service process of the application. It is used to implement user-defined signal processing callback functions, receive a first user-defined signal and a second user-defined signal, and generate function request code. The function request code is obtained by calculating the first signal count of the first user-defined signal and the second signal count of the second user-defined signal. The background service process is responsible for managing the operation of the optical ranging module.

[0036] The control script module is used to provide external control scripts; wherein, the external control scripts are sent to the signal processing module by the user by inputting the function request code and triggering a user-defined signal.

[0037] A fourth aspect of this application provides a background service process adjustment device, comprising:

[0038] Central processing unit, memory, input / output interfaces, wired or wireless network interfaces, and power supply;

[0039] The memory is either a short-term storage memory or a persistent storage memory;

[0040] The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the background service process adjustment method described in the first aspect.

[0041] A fifth aspect of this application provides a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the background service process adjustment method described in the first aspect.

[0042] A sixth aspect of this application provides a computer program product, the computer program product including instructions that, when executed on a computer, cause the computer to perform the background service process adjustment method described in the first aspect.

[0043] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: The background service process adjustment method disclosed in this application generates function request code by receiving user-defined signal combinations at runtime, enabling the background service process to dynamically execute predefined debugging or control operations (such as status output and parameter adjustment) without interruption or restart. Its implementation is simple and non-intrusive, significantly improving the efficiency and maintainability of online system debugging, and is particularly suitable for embedded systems and other environments where direct interaction is difficult. Attached Figure Description

[0044] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings.

[0045] Figure 1 This is a schematic diagram of the architecture of an optical ranging system disclosed in an embodiment of this application;

[0046] Figure 2 This is a flowchart illustrating a method for adjusting a background service process disclosed in an embodiment of this application;

[0047] Figure 3 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application;

[0048] Figure 4 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application;

[0049] Figure 5 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application;

[0050] Figure 6 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application;

[0051] Figure 7 This is a schematic diagram of the structure of a background service process adjustment system disclosed in an embodiment of this application;

[0052] Figure 8 This is a schematic diagram of the structure of a background service process adjustment device disclosed in an embodiment of this application. Detailed Implementation

[0053] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0054] It should be noted that the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0055] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0056] To resolve the technical challenges described above as much as possible, please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating a method for adjusting a background service process disclosed in an embodiment of this application. It includes steps 201-204.

[0057] 201. When the application starts, register signal handling callback functions for the first user-defined signal and the second user-defined signal.

[0058] In some embodiments, when the application starts, a user signal handling callback function is registered for the first user-defined signal SIGUSR1 and the second user-defined signal SIGUSR2 as an entry point for a debugging backdoor.

[0059] For ease of understanding, the above names will be explained below.

[0060] Linux signals are a fundamental mechanism for inter-process communication in Linux and Unix-like operating systems. They are asynchronous notifications sent to a process or a specific thread within a process to inform it that an event has occurred. When a signal arrives, the process temporarily suspends its normal execution flow and immediately executes the specific code bound to that signal (called the signal handler function). After execution, it (usually) resumes its original work.

[0061] Source of the signal:

[0062] Kernel: For example, when a process performs an illegal operation (such as dividing by zero or accessing an illegal memory address), the kernel will send signals such as SIGFPE and SIGSEGV to it.

[0063] Other processes: A process can send a signal to another process through a system call (such as kill()).

[0064] User terminal: For example, pressing Ctrl+C on the keyboard sends a SIGINT (interrupt) signal to the foreground process.

[0065] Signal handling methods: A process can handle received signals in three ways:

[0066] 1. Ignore: Discard the signal directly without any processing (but the SIGKILL and SIGSTOP signals cannot be ignored).

[0067] 2. Perform default action: Each signal has a predefined default behavior, which is usually one of the following:

[0068] Term: Terminates the process. Core: Terminates the process and generates a core dump file (for debugging). Ign: Ignores signals. Stop: Suspends (stops) the process. Cont: Resumes the process if it has been suspended.

[0069] 3. Capturing: A process can pre-register a custom function (signal handler), which the kernel will call when a signal arrives. This allows the program to execute custom logic when a signal occurs.

[0070] SIGUSR1 and SIGUSR2 signals are explained in detail. SIGUSR1 and SIGUSR2 are two very special signals; their full names are User-DefinedSignal1 and User-DefinedSignal2.

[0071] Signal number:

[0072] SIGUSR1 is usually numbered 10. SIGUSR2 is usually numbered 12.

[0073] Design concept and core features:

[0074] 1. No predefined meaning: Unlike SIGINT (meaning interrupt) and SIGTERM (meaning termination), SIGUSR1 and SIGUSR2 have no fixed meaning at the operating system level.

[0075] 2. User-defined: These are designed to allow application developers to define their purpose. Use them for any purpose the user desires, such as triggering a specific action, switching operating modes, requesting status reports, etc.

[0076] 3. Default behavior: Their default behavior is to terminate the process. Therefore, if you want to use them for something useful instead of simply killing the process, you must catch them and provide a custom signal handler function.

[0077] Therefore, in this implementation, since SIGUSR1 and SIGUSR2 have no system-level use, using them will not interfere with other standard signal processing logic of the program. Thus, SIGUSR1 can be defined as "incrementing the tens digit" and SIGUSR2 as "incrementing the units digit," thereby encoding a large number of different commands through combination, as described in the previous scheme. Furthermore, this provides a standardized method for asynchronously controlling a running background process (daemon) from the outside (via the kill command or script) without requiring the process to be waiting for terminal input or listening on a network port.

[0078] In some embodiments, taking a Linux background daemon as an example, the `signal()` or `sigaction()` function is called in the application initialization code to register callback functions for SIGUSR1 and SIGUSR2. For example, the code could be:

[0079] #include<signal.h>

[0080] #include<unistd.h>

[0081] #include<stdio.h>

[0082] static int sigusr1_count = 0, sigusr2_count = 0;

[0083] static volatile sig_atomic_t timer_started = 0; / / Mark whether the timer has been started?

[0084] static volatile sig_atomic_t request_processing = 0; / / Marks whether a request is being processed.

[0085] void signal_handler(int sig);

[0086] int main() {

[0087] signal(SIGUSR1, signal_handler);

[0088] signal(SIGUSR2, signal_handler);

[0089] printf("Starting to monitor SIGNSR1 and SIGNSR2 signals...\n");

[0090] printf("Process PID: %d\n", getpid());

[0091] / / ... Other normal business code

[0092] }

[0093] The description of the timer will be in Figure 5 The embodiments shown are described in detail, and will not be repeated here.

[0094] 202. Receive at least one first user-defined signal and a second user-defined signal sent from outside, and within a preset time window, count the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal received.

[0095] In some embodiments, at least one SIGUSR1 signal and SIGUSR2 signal transmitted externally are received. Simultaneously, within a preset time window, the number of first SIGUSR1 signals and the number of second SIGUSR2 signals received within the application can be counted.

[0096] In some embodiments, a time window can be set in the `signal_handler` function to count the number of signals. Simultaneously, global variables are used to record the counts of SIGUSR1 and SIGUSR2, and the RequestCode is calculated. Specifically, the code will be... Figure 5 The embodiments shown are described in detail.

[0097] 203. Generate a function request code based on the number of the first signal and the number of the second signal.

[0098] In some embodiments, the main program sets a predetermined time period (e.g., within a time window since the first SIGUSR1 or SIGUSR2 signal is received) in the user signal processing function, monitors the received SIGUSR1 or SIGUSR2 signal within this time window, and then calculates the function request code to obtain the function request code.

[0099] 204. Based on the function request code and the predefined function mapping table, call the signal processing callback function to execute the corresponding backdoor operation.

[0100] In some embodiments, a signal processing callback function can be invoked to execute a corresponding backdoor operation based on a function request code and a predefined function mapping table. The predefined function mapping table maps different function request codes to different signal processing callback functions to complete function calls, including at least one of a status information output function for debugging, a debug log level switching function, a data capture function, or an algorithm module switch control function. Backdoor operations include at least one of outputting internal status, switching operating modes, modifying configuration parameters, or executing debugging functions.

[0101] In some embodiments, the request code is the sequence number, which corresponds to the function to be executed (backdoor operation). In this embodiment, a lookup table between sequence numbers and function functions is set up within the system, as follows:

[0102] 1. dump_status() / / Prints some important statuses of the process;

[0103] 2. enable_debug_log() / / Enables more debugging information for better viewing of the software execution path;

[0104] 3. disable_debug_log() / / Disable more debugging information (restores normal state after using the above functions);

[0105] 4. dump_calibrate_data() / / Save calibration data to a file;

[0106] 5. dump_100_frames_raw_data() / / Dumps 100 frames of raw data to the specified folder;

[0107] 6. dump_100_frames_pointcloud_data() / / Dump 100 frames of point cloud data to the specified folder;

[0108] 7. enable_frame_cost_time() / / Enables frame decoding and time consumption statistics and output for various algorithms;

[0109] 8. disable_frame_cost_time() / / Disables frame decoding and the time consumption statistics and output of various algorithms;

[0110] 9. disable_confidence_filter_algo() / / Disables the function of filtering low confidence points based on confidence level;

[0111] 10. re-enable_confidence_filter_algo() / / Re-enable the function of filtering low confidence points based on confidence level;

[0112] 11. disable_walkerror_algo() / / Disable walkerror algorithm handling (this feature is enabled by default; it can be temporarily disabled for debugging purposes).

[0113] 12. re-enable_walkerror_algo() / / Re-enable the walkerror algorithm processing;

[0114] 13. disable_undistort_algo() / / Disable undistort algorithm processing (this function is enabled by default, and can be temporarily disabled for debugging purposes);

[0115] 14. re-enable_undistort_algo() / / Re-enable the undistort algorithm processing;

[0116] Based on the above-mentioned feasible function mapping table, it can be seen that a 2-digit function request code can correspond to 99 function calls to execute the corresponding backdoor operations.

[0117] Furthermore, by combining the aforementioned function request code with the function mapping table, this embodiment can dynamically call functions without interrupting the main program and expand function functionality. For example, by calling the `signal-user` function, where the user sets the function, dynamic calling can be achieved without interrupting the main program. Simultaneously, using one `signal-user` function as a counter, with each count corresponding to a function, can expand to 9 functions. Using two `signal-user` functions as counters, with each count corresponding to a function, can expand to 99 functions.

[0118] This embodiment discloses a method for adjusting background service processes. By registering processing functions for SIGUSR1 and SIGUSR2 signals and defining signal combination encoding rules, dynamic control of the background service process is achieved. Without interrupting process execution or requiring additional communication modules, external users can flexibly trigger various predefined debugging and control functions (such as status output, log switching, and algorithm on / off) by sending specific signal sequences. This method significantly improves the runtime observability and debuggability of background services in embedded and server environments, and has advantages such as simple implementation, low resource consumption, strong scalability, and secure controllability.

[0119] In this embodiment, the function request code can be calculated and obtained through a function request code calculation formula. Please refer to [link to relevant documentation]. Figure 3 , Figure 3 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application. It includes step 301.

[0120] 301. Input the counts of the first signal and the counts of the second signal into the function request code calculation formula, calculate and obtain the function request code.

[0121] In some embodiments, the first signal count of the first user-defined signal and the second signal count of the second user-defined signal are input into the function request code calculation formula to calculate and obtain the function request code. The function request code calculation formula is as follows: , For feature request code, For the first signal count, This represents the number of times the second signal is received.

[0122] This embodiment discloses a method for adjusting background service processes. By defining and implementing a function request code calculation formula based on the combination of SIGUSR1 and SIGUSR2 signal counts, external asynchronous signals are converted into precise digital instructions. This design can encode up to 99 different functions using only two reserved signals, achieving a significant expansion of the instruction space. Its calculation process is simple and efficient, with no additional parsing overhead, ensuring rapid response even in resource-constrained embedded environments. This mechanism allows users to accurately and reliably trigger corresponding predefined backdoor operations by sending standard signals of varying counts, significantly improving the flexibility, accuracy, and system compatibility of dynamic debugging and control.

[0123] In this embodiment, the corresponding function request code can be obtained through an external script. Please refer to [link / reference]. Figure 4 , Figure 4 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application. It includes steps 401-403.

[0124] 401. Design external control scripts.

[0125] In some embodiments, an external control script may be set up. For example, a shell script may be set up. This shell script can be implemented by writing a bash script, such as backdoor_request_code.sh.

[0126] 402. Based on the external control script, receive the function request code and target process identifier input by the user.

[0127] In some embodiments, the shell script receives a function request code and a target process identifier (PID) input by the user. The function request code can be understood as the coded sequence number (or request code) from 1 to 99 mentioned above, and the corresponding target process identifier (PID) can be understood as the identifier that controls the main program to switch to the execution of the subroutine.

[0128] 403. Based on the function request code, calculate the number of times the first user-defined signal and the second user-defined signal need to be sent, and send the first user-defined signal and the second user-defined signal to the target process in a predetermined sending order and at a sending interval.

[0129] In some embodiments, the shell script parses the above parameters (including the function request code) to calculate the number of times the SIGUSR1 and SIGUSR2 signals need to be sent, and uses the kill command to send the SIGUSR1 and SIGUSR2 signals to the target process in a predetermined sending order and at a sending interval.

[0130] In some embodiments, a shell script can be implemented using the following code:

[0131] #! / bin / bash

[0132] if [ $# -ne 2 ]; then

[0133] echo "Usage: $0" <requestcode> <pid>"

[0134] echo "Example: $0 11 1234"

[0135] exit 1

[0136] if

[0137] REQUEST_CODE=$1

[0138] PID=$2

[0139] # Calculate the number of signals that need to be sent

[0140] SIGUSR1_COUNT=$((REQUEST_CODE / 10))

[0141] SIGUSR2_COUNT=$((REQUEST_CODE % 10))

[0142] echo "Sent signals to process $PID: SIGUSR1 x $SIGUSR1_COUNT, SIGUSR2 x $SIGUSR2_COUNT"

[0143] # Send SIGUSR1 signal

[0144] for ((i=0; i<$SIGUSR1_COUNT; i++)); do

[0145] kill -SIGUSR1 $PID

[0146] sleep 0.1 # Short interval to ensure signal sequence

[0147] done

[0148] # Send SIGUSR2 signal

[0149] for ((i=0; i<$SIGUSR2_COUNT; i++)); do

[0150] kill -SIGUSR2 $PID

[0151] sleep 0.1

[0152] done

[0153] echo "Signal sent successfully. Please pay attention to the output of the corresponding debugging backdoor function of the target process."

[0154] This embodiment discloses a method for adjusting background service processes. By designing and implementing an independent external control script (such as a shell script), it provides users with a simple, automated, and error-free signal sending tool. The script receives the user-input function request code and the target process PID, automatically parses and accurately calculates the required number of SIGUSR1 and SIGUSR2 signals to be sent, and then reliably sends the signals via the system kill command according to a preset order and interval (e.g., 0.1 seconds). This design encapsulates the complex signal combination encoding and sending process into a simple command-line operation, significantly reducing the user's learning curve and the risk of operational errors, while ensuring the timing accuracy and repeatability of signal sending. This makes the entire dynamic debugging and control process more efficient, convenient, and reliable.

[0155] Please see Figure 5 , Figure 5 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application. It includes steps 501-504.

[0156] 501. When the first user-defined signal or the second user-defined signal is received for the first time, start the timer.

[0157] In some embodiments, during the main program's execution, a timer is started when the SIGUSR1 and SIGUSR2 signals are first received. For example, as described above, a timer (e.g., 3 seconds) is set in the signal_handler function.

[0158] 502. Within the time window set by the timer, accumulate the number of times the first user-defined signal and the second user-defined signal are received.

[0159] In some embodiments, the number of signal receptions is counted within a time window set by the timer. Specifically, global variables can be used to accumulate the number of times the SIGUSR1 signal and the SIGUSR2 signal are received.

[0160] In other feasible technical solutions, if the system is processing a user request, then step 504 is executed.

[0161] 503. When the timer expires, generate a function request code based on the cumulative number of receptions and trigger the backdoor operation.

[0162] In some embodiments, when the timer expires, a function request code is generated based on the cumulative number of times the SIGUSR1 signal and the SIGUSR2 signal are received. This code, combined with a predefined function mapping table, calls the signal processing callback function to execute the corresponding backdoor operation. The formula for generating the function request code is as follows: The specifics will not be elaborated here.

[0163] 504. During the processing time of a function request code, ignore the first and second user-defined signals received during the processing time.

[0164] As shown above, if the system is currently processing a user request, i.e., within the time period of the backdoor operation corresponding to the function request code, then the SIGUSR1 and SIGUSR2 signals received during this time period are ignored.

[0165] To facilitate understanding of this embodiment, the following examples are provided in code form, for example:

[0166] void signal_handler(int sig) {

[0167] if (request_processing) / / If the system is processing a user request, ignore the received SIGUSR1 or SIGUSR2 signal.

[0168] return;

[0169] if (sig == SIGUSR1) {

[0170] sigusr1_count++;

[0171] } else if (sig == SIGUSR2) {

[0172] sigusr2_count++;

[0173] }

[0174] / / If this is the first time a signal has been received, start the timer.

[0175] if (!timer_started) {

[0176] timer_started = 1;

[0177] / / Set to send SIGALRM signal after 3 seconds

[0178] alarm(3);

[0179] / / Register the SIGALRM handler function

[0180] signal(SIGALRM, timer_handler);

[0181] }

[0182] }

[0183] Furthermore, after the timer expires, the corresponding operation is executed based on the function request code, such as printing logs or modifying configurations. Specific details are not limited here.

[0184] This embodiment discloses a method for adjusting background service processes. By introducing a timer mechanism, it achieves accurate capture and reliable parsing of user-defined signal combinations. When a SIGUSR1 or SIGUSR2 signal is received for the first time, a timer is started. Within a preset time window, the number of subsequent signals is accumulated. After the timeout, a unified function request code is generated and the corresponding backdoor operation is triggered. This design effectively distinguishes between consecutive independent operation requests, preventing interference and misjudgment between signals. Simultaneously, the system automatically ignores newly arriving signals while processing a request, avoiding operation overlap and state confusion. This time-window-based signal collection and anti-re-entry processing mechanism significantly improves the reliability, accuracy, and anti-interference capability of the dynamic debugging and control process, ensuring stable response of the background service under high concurrency or intermittent signal scenarios.

[0185] After completing the background service process for a user request, execution can jump back to the main program. See details... Figure 6 , Figure 6 This is a flowchart illustrating another method for adjusting a background service process disclosed in an embodiment of this application. It includes step 601.

[0186] 601. Reset the counter variable and status flag used to count the number of user-defined signals in preparation for responding to the next user function request.

[0187] In some embodiments, after the backdoor operation (subroutine) corresponding to the current signal processing callback function is executed, the counter variable and status flag used to count the number of user-defined signals need to be reset in order to prepare for the next user function request.

[0188] Among other feasible technical solutions, the function request code can be cleared. It then resets the state and counter variables to await the next request. Simultaneously, it jumps to the main program to continue executing the main program's service process.

[0189] To facilitate understanding of this embodiment, the following examples are provided in code form, for example:

[0190] void timer_handler() {

[0191] int request_code = sigusr1_count * 10 + sigusr2_count; / / A maximum of 99 request_codes are allowed.

[0192] printf("RequestCode: %d\n", request_code);

[0193] request_processing = 1;

[0194] / / Perform different backdoor operations based on request_code

[0195] switch (request_code) {

[0196] case 1:

[0197] printf("Function 1: Output status information\n");

[0198] dump_status(); / / Prints some important statuses

[0199] break

[0200] case 2:

[0201] printf("Executing function 2: Open more debug information\n");

[0202] enable_debug_log(); / / Enable more debugging information

[0203] break

[0204] case 3:

[0205] printf("Executing function 3: Open more debug information\n");

[0206] disable_debug_log(); / / Enable more debugging information

[0207] break

[0208] / / ... Up to 99 debugging backdoor functions

[0209] default:

[0210] printf("Unknown function request code: %d\n", request_code);

[0211] break

[0212] }

[0213] / / Reset the state to prepare for the next request.

[0214] sigusr1_count = 0;

[0215] sigusr2_count = 0;

[0216] timer_started = 0;

[0217] request_processing = 0;

[0218] }

[0219] This embodiment discloses a method for adjusting background service processes. After each backdoor operation, the counting variables (such as sigusr1_count and sigusr2_count) and related status flags (such as timer_started and request_processing) used to count the number of signals are systematically reset, ensuring the integrity and sustainability of the debugging control mechanism's state. This design allows the process to clearly and without residue terminate the current request processing and immediately return to its initial ready state, ready to respond to new instructions at any time. This automated state reset mechanism effectively prevents problems such as signal misinterpretation, functional malfunction, or request blocking caused by residual variables or uncleared flags, thereby ensuring the reliability, consistency, and long-term operational stability of the dynamic debugging system during continuous, multiple calls.

[0220] One of the feasible technical solutions can be found in [reference]. Figure 1 , Figure 1 This is a schematic diagram of the architecture of an optical ranging system disclosed in an embodiment of this application.

[0221] Combination Figure 1 As shown, the optical ranging system includes an optical ranging module, a signal processing module, and a control script module. The optical ranging module is used to perform distance measurement tasks.

[0222] The signal processing module, integrated into the background service process of the application, is used to implement user-defined signal processing callback functions, receive a first user-defined signal and a second user-defined signal, and generate function request code; wherein, the function request code is obtained by calculating the first signal count of the first user-defined signal and the second signal count of the second user-defined signal; the background service process is responsible for managing the operation of the optical ranging module.

[0223] The control script module is used to provide external control scripts (such as shell); the external control script is sent to the signal handling module by the user by entering a function request code and triggering a user-defined signal (such as RequestCode).

[0224] In some embodiments, the optical ranging system can dynamically adjust the behavior of the ranging system, such as adjusting calibration parameters, outputting measurement data, or diagnosing errors.

[0225] In some embodiments, in conjunction with the above Figures 2 to 6 In the illustrated embodiment, in the optical ranging system, a background service process controls the laser emission and reception modules. Using the adjustment method proposed in this embodiment, the user can dynamically adjust the behavior during system runtime.

[0226] A shell script sends a RequestCode (e.g., "31"), corresponding to three SIGUSR1 signals and one SIGUSR2 signal, triggering the calibration mode of the ranging system. Upon receiving the signals, the service process performs the calibration operation and outputs the results without interrupting the measurement task. This method significantly improves system maintainability and debugging efficiency, and is particularly suitable for remote diagnostics in embedded environments.

[0227] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the steps or stages of other steps.

[0228] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a background service process adjustment system disclosed in an embodiment of this application.

[0229] Registration unit 701 is used to register signal processing callback functions for the first user-defined signal and the second user-defined signal when the application starts;

[0230] The receiving unit 702 is used to receive at least one first user-defined signal and a second user-defined signal sent from the outside, and to count the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal within a preset time window.

[0231] The generation unit 703 is used to generate a function request code based on the first signal count and the second signal count;

[0232] Calling unit 704 is used to call the signal processing callback function to execute the corresponding backdoor operation based on the function request code and the predefined function mapping table.

[0233] For example, the system further includes: a computing unit 705;

[0234] Calculation unit 705 is used to input the first signal count and the second signal count into the function request code calculation formula, calculate and obtain the function request code; wherein, the function request code calculation formula is: , For feature request code, For the first signal count, This represents the number of times the second signal is received.

[0235] For example, the method further includes: a design unit 706;

[0236] Design unit 706 is used to design external control scripts;

[0237] The receiving unit 702 is also used to receive the function request code and target process identifier input by the user according to the external control script;

[0238] The calculation unit 705 is also configured to calculate the number of times the first user-defined signal and the second user-defined signal need to be sent according to the function request code, and send the first user-defined signal and the second user-defined signal to the target process in a predetermined sending order and sending interval.

[0239] For example, the system includes: a startup unit 707;

[0240] The startup unit 707 is used to start the timer when a first user-defined signal or a second user-defined signal is received for the first time.

[0241] The calculation unit 705 is specifically used to accumulate the number of times the first user-defined signal and the number of times the second user-defined signal are received within the time window set by the timer.

[0242] The generation unit 703 is specifically used to generate a function request code based on the accumulated number of receptions after the timer expires, and to trigger a backdoor operation; wherein the accumulated number of receptions includes the number of receptions of the first user-defined signal and the number of receptions of the second user-defined signal.

[0243] For example, the system further includes: an execution unit 708;

[0244] The execution unit 708 is configured to ignore the first user-defined signal and the second user-defined signal received during the processing time period when a function request code is being processed.

[0245] For example, the system also includes:

[0246] The execution unit 708 is also used to reset the counter variable and status flag used to count the number of user-defined signals in preparation for responding to the next user function request.

[0247] For example,

[0248] A predefined function mapping table is used to map different function request codes to different signal processing callback functions to complete function calls, including at least one of the following: a status information output function for debugging, a debug log level switching function, a data capture function, or an algorithm module switch control function;

[0249] Backdoor operations include at least one of the following: outputting internal status, switching operating modes, modifying configuration parameters, or executing debugging functions.

[0250] Please refer to the following: Figure 8 The schematic diagram of a background service process adjustment device disclosed in this application includes:

[0251] Central processing unit 801, memory 805, input / output interface 804, wired or wireless network interface 803, and power supply 802;

[0252] Memory 805 is either a short-term storage memory or a persistent storage memory;

[0253] The central processing unit 801 is configured to communicate with the memory 805 and execute instructions stored in the memory 805 to perform the aforementioned operations. Figures 2 to 6 Method for adjusting the background service process in any of the illustrated embodiments.

[0254] This application also provides a chip system, which includes at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform the aforementioned... Figures 2 to 6 Method for adjusting the background service process in any of the illustrated embodiments.

[0255] This application also provides a computer-readable storage medium, which includes instructions that, when executed on a computer, cause the computer to perform the aforementioned actions. Figures 2 to 6 Method for adjusting the background service process in any of the illustrated embodiments.

[0256] This application also provides a computer program product containing instructions, which, when run on a computer, causes the computer to perform the aforementioned... Figures 2 to 6 Method for adjusting the background service process in any of the illustrated embodiments.

[0257] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0258] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0259] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0260] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0261] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.< / pid> < / requestcode>

Claims

1. A method for adjusting background service processes, characterized in that, The method includes: When the application starts, register signal handling callback functions for the first user-defined signal and the second user-defined signal; Receive at least one first user-defined signal and one second user-defined signal sent from outside, and within a preset time window, count the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal received; Generate a function request code based on the number of the first signal and the number of the second signal; Based on the function request code and the predefined function mapping table, the signal processing callback function is called to execute the corresponding backdoor operation.

2. The method for adjusting background service processes according to claim 1, characterized in that, The step of generating a function request code based on the first signal count and the second signal count includes: Input the first signal count and the second signal count into the function request code calculation formula to calculate and obtain the function request code; wherein, the function request code calculation formula is: The The function request code, the For the first signal number, the The number of times the second signal is received.

3. The method for adjusting the background service process according to claim 1 or 2, characterized in that, The method further includes: Design external control scripts; According to the external control script, the function request code and target process identifier input by the user are received; Based on the function request code, calculate the number of times the first user-defined signal and the second user-defined signal need to be sent, and send the first user-defined signal and the second user-defined signal to the target process in a predetermined sending order and at a sending interval.

4. The method for adjusting background service processes according to claim 1, characterized in that, The step of counting the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal within a preset time window includes: The timer is started when the first user-defined signal or the second user-defined signal is received for the first time. Within the time window set by the timer, the cumulative number of times the first user-defined signal and the second user-defined signal are received is calculated. When the timer expires, the function request code is generated based on the cumulative number of receptions, and the backdoor operation is triggered; wherein, the cumulative number of receptions includes the number of receptions of the first user-defined signal and the number of receptions of the second user-defined signal.

5. The method for adjusting background service processes according to claim 4, characterized in that, The method further includes: During the processing time period when a feature request code is being processed, the first user-defined signal and the second user-defined signal received during the processing time period are ignored.

6. The method for adjusting background service processes according to claim 1, characterized in that, After executing the corresponding backdoor operation, the method further includes: Reset the counter variable and status flags used to count the number of user-defined signals in preparation for responding to the next user's feature request.

7. The method for adjusting background service processes according to any one of claims 1 to 6, characterized in that, The predefined function mapping table is used to map different function request codes to different signal processing callback functions to complete function calls, including at least one of the following: a status information output function for debugging, a debug log level switching function, a data capture function, or an algorithm module switch control function; The backdoor operation includes at least one of outputting internal status, switching operating modes, modifying configuration parameters, or executing debugging functions.

8. An optical ranging system, characterized in that, The method for adjusting the background service process as described in any one of claims 1-7 includes: an optical ranging module, a signal processing module, and a control script module; The optical ranging module is used to perform distance measurement tasks; The signal processing module is integrated into the background service process of the application. It is used to implement user-defined signal processing callback functions, receive a first user-defined signal and a second user-defined signal, and generate function request code. The function request code is obtained by calculating the first signal count of the first user-defined signal and the second signal count of the second user-defined signal. The background service process is responsible for managing the operation of the optical ranging module. The control script module is used to provide external control scripts; wherein, the external control scripts are sent to the signal processing module by the user by inputting the function request code and triggering a user-defined signal.

9. A system for adjusting background service processes, characterized in that, The system includes: The registration unit is used to register signal handling callback functions for the first user-defined signal and the second user-defined signal when the application starts. The receiving unit is configured to receive at least one first user-defined signal and one second user-defined signal transmitted from outside, and within a preset time window, count the number of first signals of the first user-defined signal and the number of second signals of the second user-defined signal received; The generation unit is configured to generate a function request code based on the number of the first signal and the number of the second signal; The calling unit is used to call the signal processing callback function to execute the corresponding backdoor operation based on the function request code and the predefined function mapping table.

10. A device for adjusting background service processes, characterized in that, The device includes: Central processing unit, memory, input / output interfaces, wired or wireless network interfaces, and power supply; The memory is either a short-term storage memory or a persistent storage memory; The central processing unit is configured to communicate with the memory and execute instructions in the memory to perform the background service process adjustment method according to any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a computer, cause the computer to perform the adjustment method for a background service process as described in any one of claims 1 to 7.

Images