CN114327404A

CN114327404A - File processing method and device, electronic equipment and computer readable medium

Info

Publication number: CN114327404A
Application number: CN202111626169.4A
Authority: CN
Inventors: 徐强
Original assignee: CCB Finetech Co Ltd
Current assignee: CCB Finetech Co Ltd
Priority date: 2021-12-28
Filing date: 2021-12-28
Publication date: 2022-04-12

Abstract

The application discloses a file processing method, a file processing device, an electronic device and a computer readable medium, which relate to the technical field of automatic program design, and one specific implementation mode comprises the following steps: receiving a file processing request, and acquiring a corresponding file descriptor; calling a constructor to generate a polling instance based on the file descriptor; calling a polling instance to register a file descriptor so as to generate a polling object; the processing of the corresponding file is performed based on the polling object. By generating the polling object, the states of the polling object can be edited simultaneously by each process, so that multiplexing of file operation can be realized based on the states of the file descriptors, one process can monitor a plurality of file descriptors, the files can be opened simultaneously by each process, sequential simultaneous reading and writing can be performed, and changes to service codes are reduced.

Description

File processing method and device, electronic equipment and computer readable medium

Technical Field

The present application relates to the field of automatic programming technologies, and in particular, to a file processing method and apparatus, an electronic device, and a computer-readable medium.

Background

At a server side of software development, frequent read-write alternation of files among processes can occur. In the actual software development, the operation of reading and writing files in the go language is blocking, when a plurality of processes frequently perform reading and writing operations on the same file, one process open performs writing operations on one file, and until the process close performs reading and writing operations on the file, other processes can perform reading and writing operations on the file, so that the efficiency of reading and writing the file is low.

In the process of implementing the present application, the inventor finds that at least the following problems exist in the prior art:

when multiple processes frequently perform read-write operations on the same file, the efficiency of the read-write processing on the file is low.

Disclosure of Invention

In view of this, embodiments of the present application provide a file processing method and apparatus, an electronic device, and a computer readable medium, which can solve the problem that when multiple processes frequently perform read/write operations on a same file, the efficiency of read/write processing on the file is low.

To achieve the above object, according to an aspect of an embodiment of the present application, there is provided a file processing method including:

receiving a file processing request, and acquiring a corresponding file descriptor;

calling a constructor to generate a polling instance based on the file descriptor;

calling a polling instance to register a file descriptor so as to generate a polling object;

the processing of the corresponding file is performed based on the polling object.

Optionally, generating a polling instance based on the file descriptor includes:

calling a constructor to create a monitoring object based on the file descriptor and encapsulate the monitoring object;

starting an independent coroutine to generate an infinite loop based on the encapsulated monitored object;

executing infinite loop, and calling a monitoring function to acquire the state of the packaged monitored object;

generating a polling instance based on the state of the encapsulated snooping object.

Optionally, invoking the polling instance to register the file descriptor, and further generating the polling object, includes:

and calling the monitored event registration function to register the file descriptor into the polling instance so as to generate a polling object.

Optionally, invoking an event registration function of the listening to register the file descriptor in the polling instance, and further generating a polling object, including:

calling a monitored event registration function to package the polling instance and the file descriptor, and setting the packaged file descriptor to be non-blocking so as to obtain a polling object.

Optionally, the processing of the corresponding file is performed based on the polling object, including:

determining an execution method type corresponding to the polling object;

and executing the processing of the corresponding file according to the execution method type.

Optionally, the method further comprises:

and acquiring the state returned by the processing of the corresponding file, and further adjusting the state of the corresponding polling object according to the returned state.

Optionally, the execution method type includes:

one or more of file reading, file writing, file reading waiting, file writing waiting and file closing.

In addition, the present application also provides a file processing apparatus, including:

the receiving unit is configured to receive a file processing request and acquire a corresponding file descriptor;

an instance generation unit configured to call a constructor to generate a polling instance based on the file descriptor;

an object generation unit configured to invoke a polling instance registration file descriptor, thereby generating a polling object;

a processing unit configured to perform processing of the corresponding file based on the polling object.

Optionally, the instance generation unit is further configured to:

Optionally, the object generation unit is further configured to:

Optionally, the processing unit is further configured to:

determining an execution method type corresponding to the polling object;

Optionally, the apparatus further comprises a state adjustment unit configured to:

Optionally, the execution method type includes:

In addition, the present application also provides a file processing electronic device, including: one or more processors; a storage device for storing one or more programs which, when executed by one or more processors, cause the one or more processors to implement the file processing method as described above.

In addition, the present application also provides a computer readable medium, on which a computer program is stored, which when executed by a processor implements the file processing method as described above.

To achieve the above object, according to still another aspect of embodiments of the present application, there is provided a computer program product.

A computer program product according to an embodiment of the present application includes a computer program, and when the computer program is executed by a processor, the computer program implements the file processing method according to an embodiment of the present application.

One embodiment of the above invention has the following advantages or benefits: the method comprises the steps of obtaining corresponding file descriptors by receiving a file processing request; calling a constructor to generate a polling instance based on the file descriptor; calling a polling instance to register a file descriptor so as to generate a polling object; the processing of the corresponding file is performed based on the polling object. By generating the polling object, the states of the polling object can be edited simultaneously by each process, so that multiplexing of file operation can be realized based on the states of the file descriptors, one process can monitor a plurality of file descriptors, the files can be opened simultaneously by each process, sequential simultaneous reading and writing can be performed, and changes to service codes are reduced.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a further understanding of the application and are not to be construed as limiting the application. Wherein:

fig. 1 is a schematic view of a main flow of a document processing method according to a first embodiment of the present application;

FIG. 2 is a schematic view of a main flow of a document processing method according to a second embodiment of the present application;

FIG. 3 is a schematic diagram of an application scenario of a file processing method according to a third embodiment of the present application;

FIG. 4 is a schematic diagram of the main units of a document processing apparatus according to an embodiment of the present application;

FIG. 5 is an exemplary system architecture diagram to which embodiments of the present application may be applied;

fig. 6 is a schematic structural diagram of a computer system suitable for implementing the terminal device or the server according to the embodiment of the present application.

Detailed Description

The following description of the exemplary embodiments of the present application, taken in conjunction with the accompanying drawings, includes various details of the embodiments of the application for the understanding of the same, which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present application. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness. According to the technical scheme, the data acquisition, storage, use, processing and the like meet relevant regulations of national laws and regulations.

Fig. 1 is a schematic diagram of a main flow of a document processing method according to a first embodiment of the present application, and as shown in fig. 1, the document processing method includes:

step S101, receiving a file processing request and acquiring a corresponding file descriptor.

In this embodiment, EPOLL is the same as EPOLL in the embodiment of the present application. epoll is the poll improved by the Linux kernel for processing large-batch file descriptors, is an enhanced version of the multiplexing IO interface select/poll under Linux, and can significantly improve the utilization rate of a system CPU under the condition that a program is only slightly active in a large number of concurrent connections. When acquiring an event, epoll does not need to traverse the entire intercepted descriptor set, as long as traversing the set of file descriptors that are asynchronously awakened by the kernel IO event and added to the Ready queue. The execution subject (for example, a server) of the file processing method may receive the file processing request by means of a wired connection or a wireless connection. Specifically, the file processing request may be a request for reading, writing, read waiting, and write waiting for a file. The embodiment of the present application does not limit the specific content of the request for file processing. After receiving the file processing request, the execution body may obtain a file path (path) and an operation mode in the file processing request, where the operation mode represents an open mode of the file, such as read, write, and the like. Then, the execution subject may open the corresponding file based on the file path and the operation mode corresponding to the acquired file processing request. After opening the corresponding file, the execution principal may receive a file descriptor back. The kernel accesses the file using a file descriptor (fd). The file descriptor is a non-negative integer. When an existing file or a new file is opened, the kernel returns a file descriptor. Reading and writing files also requires the use of file descriptors to specify the files to be read and written. A file descriptor is a handle, represented by an unsigned integer, that a process uses to identify an open file. The file descriptor is associated with a file object that includes relevant information (e.g., the open mode of the file, the location type of the file, the initial type of the file, etc.), referred to as the context of the file.

Step S102, a constructor is called to generate a polling instance based on the file descriptor.

And (3) constructing a function: when called with the new key, some kind of function, called constructor, can be implemented. The core of the constructor is the key new, and for example, new f1,// f1{ } and new f1() have the same effect and are run by the new, which is called as the constructor, and are used for creating an instance corresponding to a class. Specifically, the process of calling the constructor to create a polling instance may be: calling a constructor to automatically create an empty object; setting readable, writable, read-waiting, write-waiting, closing and other attributes for the file descriptor, associating the attributes with a this pointer inside the constructor, and further pointing the this pointer inside the constructor to the created object (namely, the function of the constructor, constructing a new object, setting the attributes and the method of the object); the created object or instantiated object (i.e., polling instance) is automatically returned after the function execution is complete. Illustratively, the polling instance may be a Poller-like instance.

In this embodiment, first, the execution agent, after receiving the file processing request, defines the file processing request for later use. Pseudo code that specifically defines the Poller type (in the embodiment of the present application, Poller type, i.e., polling type) is as follows:

// define Poller type for later use

type Poller struct{

Encapsulate epoll related information (i.e. encapsulate callback function related information above the listener file descriptor)

}

Wherein "type Poller struct {" means that a type named Poller is defined using a structure.

Furthermore, the execution body may also define a Polable type for later use, which is the type of the polling object. The specific pseudo-code is as follows:

// defining Polable types for later use

type Pollable struct{

// encapsulating Poller objects and File descriptors df

}

Wherein, the meaning of "type Polable struct {" is to define a type named Polable using a structure.

The epoll uses a mechanism of an event callback function to detect whether a file descriptor is ready, the ready file descriptor is added to a ready queue, and a listening function, for example epoll _ wait, can directly access the ready queue to determine the ready file descriptor. Specifically, epoll will inform which binary stream what I/O events occurred. epoll is event driven (each event is associated with a file descriptor fd), where operations on these binary streams are meaningful. epoll related information includes: a file descriptor. The file descriptor is an integer number, and the descriptor of the demo. Txt fd is 3. The execution body may encapsulate epoll related information associated with the file descriptor, thereby defining the Poller type.

After defining the Poller type, the execution agent may call a New function to generate a Poller class instance based on the Poller type defined by the epoll related information associated with the file descriptor.

The specific go language pseudocode that generates the Poller class instance is as follows: p, err ═ New (), meaning an instance p that calls the New function to get the Poller type, where err is the error information. The New function generates an object by default. This inside the New function by default points to the object generated by New. This object, generated by the New function, is the default return value of the function.

Specifically, the go language pseudocode that generates Poller class instances is as follows:

// provide an example of a New function for creating Poller types

func New(){

Syscall EPOLL CREATE1, syscall EPOLL cloxec CREATEs an EPOLL object and packages it in one

If a separate coroutine is initiated independently, the epoll object is made into an infinite for loop handling system event notification

go for{

SYS _ EPOLL _ WAIT gets the state of the snooped file descriptor through a system call syscall

If the status of the snooped file descriptor is faulty or fd is closed, then the for loop is skipped

If event notification is syscall, EPLLOUT, wake up processing function to do file operation

If not, continue the present for loop

Close to the system call syscall to end the file descriptor when the loop is popped

}

// function returns previously packed epoll object Poller

}

Specifically, the previously encapsulated epoll object Poller returned by the function is the generated polling instance (e.g., Poller-like instance).

Wherein, the meaning of "func New () {" in the above go language pseudo code for generating Poller class example is to define a function New which is disclosed to the outside; syscall. syscall _ EPOLL _ CREATE1 "means that the EPOLL instance is created for a system call; epoll _ cloxec means a parameter used when creating an epoll instance, which will automatically close the epoll handle when exec is executed; syscall. sys _ EPOLL _ WAIT "means the status flag of the EPOLL instance by which the status of the file descriptor is identified; epollout means the status flag of the epoll instance, representing the output event, at which time the procedure for handling the event is removed; close means to close the file descriptor.

Step S103, calling the polling instance registration file descriptor, and further generating a polling object.

Specifically, the polling instance may be, for example, a Poller-type instance. A file descriptor df is registered to be added to the snooped event loop and a poll object is returned (for file read/write/close/wait operations). The go language pseudo code that generates the polling object is implemented as follows:

method Register for Poller object: a file descriptor df is registered to be added into the epoll event loop and a Polable object is returned (for file read/write/close/wait operations)

func(*Poller)Register(fd){

// encapsulating a Pollable object containing Poller object and file descriptor fd

Set file descriptor fd to non-blocking (using system call syscall SetNonBlock)

v/Poller object registration file descriptor fd created with previous New () function as follows:

v/register File descriptor fd in EPOLL by System calls syscall, SYS _ EPLL _ CTL and syscall, EPLL _ CTL _ ADD

// this function returns the previously encapsulated Polable object (i.e., returns the Polling object)

}

Wherein, the meaning of the 'Register' in the go language pseudo code for generating the polling object (namely, the Polable object) is registration; "func (. Poller) Register (fd) {" means an execution method Register that defines Poller type, with fd (file descriptor) as a parameter; setnoblock means that the file descriptor fd is set to a non-blocking state; syscall, sys _ EPOLL _ CTL "means that the EPOLL instance is changed by using the system call, the EPOLL _ CTL adds, modifies or deletes the event of interest to the EPOLL object, returns 0 indicating success, otherwise returns-1, at this time, the error type needs to be judged according to the errno error code, and the event returned by the EPOLL _ WAIT method is inevitably added to the EPOLL through the EPOLL _ CTL; epoll CTL ADD means that a file descriptor is added to the epoll instance to be managed.

In step S104, processing of the corresponding file is executed based on the polling object.

Specifically, the polling object may support various methods Read, Write, waittread, waittwrite, Close for file operations.

Specifically, the process of executing the corresponding file based on the polling object includes: and determining the execution method type corresponding to the polling object.

Specifically, the execution method types include: one or more of file reading, file writing, file reading waiting, file writing waiting and file closing.

In response to the execution method type being file read, the execution subject may call a file reading function that is open to the outside, for example, "func (p × policy) read (buff) {" to execute the file read operation.

Illustratively, the pseudo code in go language for executing the subject to perform the file read operation is as follows:

// read File function open to outside

func(p*Pollable)Read(buff){

for {// read file content cyclically

Read file to buff using system call syscall

If the status returned by the previous read file is not syscall

V/execution System calls to Syscar, EPOLL _ CTL _ MOD, Syscar, EPLLONESHOT | Syscar

// then jump out of this function

}

Wherein, the meaning of "func (p × Polable) Read (buff) {" in the go language pseudo code for executing the file reading operation is to define an execution method Read of Polable type, and buff is taken as a parameter; "syscall. epoll _ CTL _ MOD" means that using this system call, the epoll instance is changed; "syscall. epollosonshort | syscall. epollin" means a parameter of Epoll that is used to set a file descriptor in Epoll to a read wait state.

In response to the execution method type being file write, the execution subject may call a write file function open to the outside, for example, "func (p × policy) write (buff) {" to execute the file write operation.

Illustratively, the go language pseudo code that executes the subject to perform the file write operation is as follows:

// write File function open to the outside

func(p*Pollable)Write(buff){

for {// circular write File

Write the Buff content to the file corresponding to the file descriptor in Polable object using System Call syscall

If the status returned by the previous write file is not syscall

V/execution System calls to Syscar, EPOLL _ CTL _ MOD, Syscar, EPLLONESHOT | Syscar, EPLLOUT of epoll, sets the Polable object to a write wait state

// then jump out of this function

}

Wherein, the meaning of "func (p × Polable) Write (buff) {" in the go language pseudo code for executing the file Write operation is an execution method Write for defining Polable type, and buff is used as a parameter; "syscall. epoll _ CTL _ MOD" means that using this system call, the epoll instance is changed; "syscall. epollosehot | syscall. epollout" means a parameter of epoll that is used to set a file descriptor in epoll to a write-wait state.

In response to the execution method type being read wait, the execution subject may call a function open to the outside, for example, "func (p × poll) waittread () {" to set the poll object to a read wait state.

Illustratively, the pseudo code in go language for executing the subject to perform the file read wait operation is as follows:

// for open-to-the-outside function, set Polable object to read wait state

func(p*Pollable)WaitRead(){

// then jump out of this function

}

The 'func (p × Polable) WaitRead () {' meaning in go language pseudo code for executing file read waiting operation is an execution method WaitRead for defining Polable type, and no parameter is included; "syscall. epoll _ CTL _ MOD" means that using this system call, the epoll instance is changed; "syscall. epollosonshort | syscall. epollin" means a parameter of epoll that is used to set a file descriptor in epoll to a read wait state.

In response to the execution method type being write wait, the execution subject may call a function open to the outside, for example, "func (p × poll) WaitWrite () {" will set the poll object to a write wait state.

Illustratively, the pseudo code in go language for executing the subject to perform the file write wait operation is as follows:

// for open-to-the-outside function, set Polable object to write wait State

func(p*Pollable)WaitWrite(){

// then jump out of this function

}

Wherein, the meaning of 'func (p × Polable) WaitWrite () {' in the go language pseudo code for executing the file write waiting operation is an execution method WaitWrite for defining Polable type, and no parameter is included; "syscall. epoll _ CTL _ MOD" means that using this system call, the epoll instance is changed; "syscall. epollosehot | syscall. epollout" means a parameter of epoll that is used to set a file descriptor in epoll to a write-wait state.

And in response to the execution method type being file closing, the execution main body may call an externally open function to close the Polable object and the file descriptor fd encapsulated by the Polable object.

Illustratively, the go language pseudo code that executes the subject to perform the file close operation is as follows:

// open to the outside function, Polable object and its encapsulated file descriptor fd closed

func(p*Pollable)Close(){

EPOLL _ CTL _ DEL deletes file descriptor fd from epoll

}

Wherein, the meaning of "func (p × Polable) Close () {" in the go language pseudo code for executing the file closing operation is one execution method Close defining Polable type, and has no parameter; epoll _ CTL _ DEL means that the file descriptor of the epoll instance is deleted using this system call.

Specifically, the file processing method further includes:

The execution agent may obtain the status of the file descriptor returned by the processing of the file, such as whether the file descriptor is ready, readable, or writable, for example. The execution body may adjust the state of the corresponding polling object (e.g., a poll object) according to the state of the returned file descriptor, for example, adjust the state of the corresponding polling object to be read waiting when the file descriptor is unreadable, and adjust the state of the corresponding polling object to be write waiting when the file descriptor is unwritable. The file descriptor which is transmitted by epoll to the user and is ready does not need to be traversed, so that the traversal time for judging whether the file transmitted to the user is ready is saved, and IO multiplexing is realized. IO multiplexing: the method is a synchronous IO model, and realizes that one process can monitor a plurality of file handles, wherein the file handles are file descriptors, once a certain file handle is ready, an application program can be informed to perform corresponding read-write operation, and the application program can be blocked and handed out to a CPU when no file handle is ready. Multiplexing refers to network connection and multiplexing refers to the same thread.

In the embodiment, a corresponding file descriptor is acquired by receiving a file processing request; calling a constructor to generate a polling instance based on the file descriptor; calling a polling instance to register a file descriptor so as to generate a polling object; the processing of the corresponding file is performed based on the polling object. By generating the polling object, the states of the polling object can be edited simultaneously by each process, so that multiplexing of file operation can be realized based on the states of the file descriptors, one process can monitor a plurality of file descriptors, the files can be opened simultaneously by each process, sequential simultaneous reading and writing can be performed, and changes to service codes are reduced.

Fig. 2 is a schematic main flow diagram of a document processing method according to a second embodiment of the present application, and as shown in fig. 2, the document processing method includes:

step S201, receiving a file processing request, and acquiring a corresponding file descriptor.

Step S202, a constructor is called to create a monitoring object based on the file descriptor and encapsulate the monitoring object.

The execution subject may associate the file descriptor with the information related to the interception, and then call a constructor based on the information related to the interception after associating the file descriptor, and create the interception object. And encapsulates the created listening object.

Step S203, an independent coroutine is started to generate an infinite loop based on the encapsulated snooping object.

The execution subject can independently start an independent coroutine, and the encapsulated monitoring object is made into an infinite loop to process the system event notification.

Step S204, an infinite loop is executed, and then a monitoring function is called to acquire the state of the packaged monitored object.

And executing an infinite loop (such as an infinite for loop), obtaining the state of the monitored file descriptor through a system call syscall. sys __ WAIT, and correspondingly updating the state of the packaged snooping object (i.e. the epoll object) according to the state of the file descriptor, wherein the state is, for example, a read waiting state or a write waiting state.

Step S205, a polling instance is generated based on the state of the packaged listening object.

The execution subject may call the constructor to generate a corresponding polling instance according to a specific state of the encapsulated snooping object, for example, a read wait state or a write wait state.

Step S206, the polling instance registration file descriptor is called, and then a polling object is generated.

Specifically, invoking the polling instance to register the file descriptor and further generate the polling object includes:

and calling an event registration function of epoll to register the file descriptor into a polling instance (namely a polling instance), and further generating a polling object (namely a polling object).

Specifically, "register to" is "encapsulate", that is, the execution subject may call an event registration function of epoll to encapsulate the file descriptor into a polling instance (i.e., a poll instance) to generate a polling object (i.e., a poll object).

Specifically, calling an event registration function of epoll to register a file descriptor in a polling instance, and further generating a polling object, includes:

and calling an event registration function of epoll to package the polling instance and the file descriptor, and setting the packaged file descriptor to be non-blocking so as to obtain a polling object.

In step S207, processing of the corresponding file is executed based on the polling object.

The embodiment of the application can realize the multiplexing of file operation, realize that each process simultaneously opens the file, sequentially and simultaneously reads and writes, and reduce the change to the service code.

Fig. 3 is a schematic view of an application scenario of a file processing method according to a third embodiment of the present application. The file processing method of the embodiment of the application can be applied to a scene that multiple processes read and write files simultaneously. As shown in fig. 3, the server 302 receives a file processing request 301, and obtains a corresponding file descriptor 303. Server 302 calls constructor 304 to generate polling instance 305 based on file descriptor 303. The server 302 invokes the poll instance 305 to register the file descriptor 303, which in turn generates a poll object 306. The server 302 performs processing of the file 307 corresponding to the file processing request 301 based on the polling object 306.

By way of example, pseudo code for implementing file processing in an embodiment of the present application is as follows:

pseudo code format for implementing multiplexing

Open ("tmp.txt"); // go language opens a file

p, err ═ New (); I/Call New function to get an instance of Poller type p

r, err ═ p.register (file.pfd); pfd, obtaining Polable object r

n, err ═ r.read (buf); read method for calling Polable object r to Read file content

…

Where "file, err ═ p.register (file.pfd)" means that a file is opened, the file is a file handle, err is error information, and "tmp.txt" is a file name.

"p, err ═ New ()" means one instance p of calling the New function to get Poller type; err is error information.

The meaning of "r, err ═ p.register (file.pfd)" is to register file descriptor file.pfd, obtain Polable object r; err is error information; pfd is the pfd attribute (file descriptor) of the file object obtained before.

Read (buf) "means to read file information, n is the length of the read content, err is error information, and buf is where the read content is written.

The embodiment of the application obtains an example object of a Poller type by calling a new function; registering file descriptor pfd by Poller object to obtain Polable object; and then the Polable object is used for performing the same file reading and writing operation as the original file reading and writing operation. The file multiplexing is realized, the file can be opened by each process at the same time, the sequence and the reading and the writing are carried out at the same time, and the change of service codes is reduced.

Fig. 4 is a schematic diagram of main units of a document processing apparatus according to an embodiment of the present application. As shown in fig. 4, the file processing apparatus includes a receiving unit 401, an instance generating unit 402, an object generating unit 403, and a processing unit 404.

The receiving unit 401 is configured to receive a file processing request and obtain a corresponding file descriptor.

An instance generation unit 402 configured to call a constructor to generate a polling instance based on the file descriptor.

An object generation unit 403 configured to invoke the polling instance registration file descriptor, thereby generating a polling object.

A processing unit 404 configured to perform processing of the corresponding file based on the polling object.

In some embodiments, the instance generation unit is further configured to: calling a constructor to create a monitoring object based on the file descriptor and encapsulate the monitoring object; starting an independent coroutine to generate an infinite loop based on the encapsulated monitored object; executing infinite loop, and calling a monitoring function to acquire the state of the packaged monitored object; generating a polling instance based on the state of the encapsulated snooping object.

In some embodiments, the object generation unit 403 is further configured to: and calling the monitored event registration function to register the file descriptor into the polling instance so as to generate a polling object.

In some embodiments, the object generation unit 403 is further configured to: calling a monitored event registration function to package the polling instance and the file descriptor, and setting the packaged file descriptor to be non-blocking so as to obtain a polling object.

In some embodiments, the processing unit 404 is further configured to: determining an execution method type corresponding to the polling object; and executing the processing of the corresponding file according to the execution method type.

In some embodiments, the apparatus further comprises a state adjustment unit, not shown in fig. 4, configured to: and acquiring the state returned by the processing of the corresponding file, and further adjusting the state of the corresponding polling object according to the returned state.

In some embodiments, performing the method type comprises: one or more of file reading, file writing, file reading waiting, file writing waiting and file closing.

In the present application, the document processing method and the document processing apparatus have corresponding relation in the specific implementation contents, and therefore, the description of the repeated contents is omitted.

Fig. 5 illustrates an exemplary system architecture 500 to which the document processing method or the document processing apparatus of the embodiments of the present application may be applied.

As shown in fig. 5, the system architecture 500 may include

terminal devices

501, 502, 503, a network 504, and a server 505. The network 504 serves to provide a medium for communication links between the

terminal devices

501, 502, 503 and the server 505. Network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

501, 502, 503 to interact with a server 505 over a network 504 to receive or send messages or the like. The

terminal devices

501, 502, 503 may have installed thereon various communication client applications, such as shopping-like applications, web browser applications, search-like applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only).

The

terminal devices

501, 502, 503 may be various electronic devices having a file processing screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 505 may be a server providing various services, such as a background management server (for example only) providing support for file processing requests submitted by users using the

terminal devices

501, 502, 503. The background management server can receive the file processing request and acquire a corresponding file descriptor; calling a constructor to generate a polling instance based on the file descriptor; calling a polling instance to register a file descriptor so as to generate a polling object; the processing of the corresponding file is performed based on the polling object. By generating the polling object, the states of the polling object can be edited simultaneously by all processes, the multiplexing of file operation is realized, the files are opened simultaneously by all processes, the reading and the writing are carried out sequentially and simultaneously, and the change to the service code is reduced.

It should be noted that the file processing method provided in the embodiment of the present application is generally executed by the server 505, and accordingly, the file processing apparatus is generally disposed in the server 505.

It should be understood that the number of terminal devices, networks, and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 6, shown is a block diagram of a computer system 600 suitable for use in implementing a terminal device of an embodiment of the present application. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data necessary for the operation of the computer system 600 are also stored. The CPU601, ROM602, and RAM603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output section 607 including a signal processing section such as a Cathode Ray Tube (CRT), a liquid crystal credit authorization inquiry processor (LCD), and the like, and a speaker and the like; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.

In particular, according to embodiments disclosed herein, the processes described above with reference to the flow diagrams may be implemented as computer software programs. For example, embodiments disclosed herein include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The above-described functions defined in the system of the present application are executed when the computer program is executed by the Central Processing Unit (CPU) 601.

It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may include, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present application may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes a receiving unit, an instance generating unit, an object generating unit, and a processing unit. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs, which when executed by a device, cause the device to receive a file processing request and obtain a corresponding file descriptor; calling a constructor to generate a polling instance based on the file descriptor; calling a polling instance to register a file descriptor so as to generate a polling object; the processing of the corresponding file is performed based on the polling object. By generating the polling object, the states of the polling object can be edited simultaneously by all processes, the multiplexing of file operation is realized, the files are opened simultaneously by all processes, the reading and the writing are carried out sequentially and simultaneously, and the change to the service code is reduced.

The computer program product of the present application includes a computer program, and the computer program realizes the file processing method in the embodiment of the present application when being executed by a processor.

According to the technical scheme of the embodiment of the application, the polling object is generated, and the states of the polling object can be edited simultaneously by all processes, so that the multiplexing of file operation can be realized based on the states of the file descriptors, one process can monitor a plurality of file descriptors, the files can be opened simultaneously by all processes, the sequence is read and written simultaneously, and the change of service codes is reduced.

The above-described embodiments should not be construed as limiting the scope of the present application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A file processing method, comprising:

calling the polling instance to register the file descriptor so as to generate a polling object;

and executing the processing of the corresponding file based on the polling object.

2. The method of claim 1, wherein generating the polling instance based on the file descriptor comprises:

calling a constructor to create a snooping object based on the file descriptor and encapsulate the snooping object;

executing the infinite loop, and calling a monitoring function to acquire the state of the packaged monitored object;

and generating a polling instance based on the state of the packaged monitoring object.

3. The method of claim 2, wherein said invoking the polling instance to register the file descriptor to generate a polling object comprises:

and calling a monitored event registration function to register the file descriptor into the polling instance so as to generate a polling object.

4. The method of claim 3, wherein the invoking the snooped event registration function registers the file descriptor in the polling instance to generate a polling object, comprising:

5. The method according to any one of claims 1-4, wherein the performing the processing of the corresponding file based on the polling object comprises:

determining the execution method type corresponding to the polling object;

and executing the corresponding file processing according to the execution method type.

6. The method of claim 5, further comprising:

7. The method of claim 5, wherein the performing the method type comprises:

8. A document processing apparatus, characterized by comprising:

an object generating unit configured to invoke the polling instance to register the file descriptor, thereby generating a polling object;

9. The apparatus of claim 8, wherein the instance generation unit is further configured to:

10. The apparatus of claim 9, wherein the object generation unit is further configured to:

11. The apparatus of claim 10, wherein the object generation unit is further configured to:

12. The apparatus according to any one of claims 8-11, wherein the processing unit is further configured to:

determining the execution method type corresponding to the polling object;

13. The apparatus of claim 12, further comprising a state adjustment unit configured to:

14. A file processing electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-7.

15. A computer-readable medium, on which a computer program is stored, which program, when being executed by a processor, is adapted to carry out the method of any one of claims 1-7.

16. A computer program product comprising a computer program, characterized in that the computer program realizes the method according to any of claims 1-7 when executed by a processor.