本文发表在 rolia.net 枫下论坛There are two different scenarios that you might have to consider.
The first one is that you only want to protect data from abnormal termination of the application process. In this scenario, the cause of the abnormal termination are due to errors occured in your process space, such as coding error, and insufficient resources, the operating
system as a whole is still healty. To solve the problem, you can have a
very simple deamon process running in the backgroud, this deamon process forks your application process as its child. This deamon process opens all the relevent fds before fork(). If the child application process is terminated somehow, either normally or abnormally, the deamon process will receive a SIGCHLD signal. The deamon process should call waitpid() function to recycle the dead child process and grab the exit status. If the exit status is 0, that means the application process has successfuly exited and the deamon process can safely exit too. However, if the exit status is not zero, something bad has happened to the child process, and the deamon process should fork a new child process in order to finish the rest of the job. The essence here is that
child process and the parent process SHARE the same kernel file pointer, if the child process advances it's file pointer, the corresponding file pointer in the parent process gets advanced too, vice versa. In Unix, there is only one kernel file descriptor for each active open() call, if you fork a child process, the parent process and child process shre the same kernel file pointer, although they keep separate versions of file descriptor in their respective process (PCB).
The second scenario is that you want to guard the whole system against the possible power failure, system panic, etc. It's not easy to come up with a very effective approach in this case, because you have to write some information out on to the hard disk, which is a very slow device. The risk of crash when you are writing onto the disk is really big, so there is no gurantee of "atomic transaction". A rough protection which can increase the chance of recovery would be to write your current position after(or before, it doesn't matter, both are unsafe) the actual read or write
operation. The current position can be the return value of the function
lseek(fd, 0, SEEK_CUR). Then, when you restart the program, it can restore the file pointer by calling lseek again.更多精彩文章及讨论，请光临枫下论坛 rolia.net
The first one is that you only want to protect data from abnormal termination of the application process. In this scenario, the cause of the abnormal termination are due to errors occured in your process space, such as coding error, and insufficient resources, the operating
system as a whole is still healty. To solve the problem, you can have a
very simple deamon process running in the backgroud, this deamon process forks your application process as its child. This deamon process opens all the relevent fds before fork(). If the child application process is terminated somehow, either normally or abnormally, the deamon process will receive a SIGCHLD signal. The deamon process should call waitpid() function to recycle the dead child process and grab the exit status. If the exit status is 0, that means the application process has successfuly exited and the deamon process can safely exit too. However, if the exit status is not zero, something bad has happened to the child process, and the deamon process should fork a new child process in order to finish the rest of the job. The essence here is that
child process and the parent process SHARE the same kernel file pointer, if the child process advances it's file pointer, the corresponding file pointer in the parent process gets advanced too, vice versa. In Unix, there is only one kernel file descriptor for each active open() call, if you fork a child process, the parent process and child process shre the same kernel file pointer, although they keep separate versions of file descriptor in their respective process (PCB).
The second scenario is that you want to guard the whole system against the possible power failure, system panic, etc. It's not easy to come up with a very effective approach in this case, because you have to write some information out on to the hard disk, which is a very slow device. The risk of crash when you are writing onto the disk is really big, so there is no gurantee of "atomic transaction". A rough protection which can increase the chance of recovery would be to write your current position after(or before, it doesn't matter, both are unsafe) the actual read or write
operation. The current position can be the return value of the function
lseek(fd, 0, SEEK_CUR). Then, when you restart the program, it can restore the file pointer by calling lseek again.更多精彩文章及讨论，请光临枫下论坛 rolia.net