I should start taking notes every day, or I don’t know where to put these notes for a while.
-
The difference between fork and vfork is that the child process of vfork shares the address space of the parent process, and the child process executes first, which means that the variables are shared. When the child process changes, the value of the parent process's variables will also be affected.
-
If the two processes write the same file using the open (O_APPEND), write system call, the calling order of the parent process and the child process is not necessarily, the writing to the file is alternate (but not overwritten), if you use fopen ("Ab"), when the c library function of fwrite, the parent process and the child process still call the order is not necessarily, but if the data written in the file is small, there is no alternation phenomenon, when the data is as large as 4096 bytes Another process writes.
But if it is open()+lseek(END), it will cause overwriting. -
, Strtok_r function
strtok_r function is a safe function for dividing strings under linux, the function declaration is as follows:
char *strtok_r(char *str, const char *delim, char **saveptr);
this function will also destroy the integrity of the decomposed string , But it saves the remaining string in the saveptr variable to ensure safety. -
When descriptor 0 and fd share the same file table entry. For example, if descriptor 0 is opened as read-only, then we only
read fd . Even if the system ignores the open mode, and the following call succeeds:
fd = open("/dev/fd/0", O_RDWR);
we still cannot write to fd. -
Specifying O_APPEND to open the file, using lseek to write to any location in the file is useless, all will be written to the end of the file. Atomic operation of open(O_APPEND )=open()+lseek(fd,0,SEK_END). open(O_APPEND) needs to specify O_WRONLY or O_RDWR
-
There are always some doubts between dup(1,0),
and it
feels strange for write(stdout,) and read(stdin,) and write(stdin,) and read(stdout,) -
#ifdef _SIZE_T
typedef _SIZE_T size_t;
#undef _SIZE_T
This form of macro definition combined with typedef allows size_t to be defined multiple times in multiple header files. It doesn’t matter. -
The book says that O_TRUNC will only truncate read-only or write-only files. Experiments show that O_TRUNC is truncated to 0 even if it is a readable and writable file
-
It must be the user’s program setting u+s to allow other users to access this user’s files through this program.
-
You can use access to test file permissions.
-
The i-node contains all file-related information: file type, file access permission bit, file length, pointer to the
data block occupied by the file, and so on. Most of the information in the stat structure is taken from the i-node. Only two
items of data are stored in the directory entry: file name and i-node number. The data type of the i-node number is ino_t. -
The reason why the directory cannot be hard-linked: The directory is not empty and cannot be deleted (see rmdir, rename) and the soft link unlink is not penetrated, so unlink a soft link directory can delete the "copy" of this directory. (Note: Unix (I'm not sure if linux is possible, I dare not try) root can hard link the directory, the author said that the file system will have problems) 13. Using macro functions will be faster than ordinary function calls such as getc, fgetc
-
fgets() is implemented with memcpy(), and memcpy is implemented with assembly.
-
In-depth understanding of dup2(fd,1) redirection: share the file table entry of fd with 1, the original content of write(fd) first find the file table entry of fd, and then find v according to the current v node pointer (fd) Node table, write information.
-
Most of the content of stat is in the v node table, and a few are in the file table items, such as file name, file read and write status,
-
Standard errors are non-cached as they should, while ordinary files
are fully cached by system default. -
sync can be used for applications such as databases, it ensures that modified blocks are written to disk immediately
-
For O_sync, O_direct has a better understanding
https://www.cnblogs.com/suzhou/p/5381738.html
I love this picture
-
caltime=time(NULL);
tm=localtime(&caltime);
(strftime(line,MAXLINE,"%a %b %d %X %Z %Y\n",tm) -
atexit(void(*func)(void))Similar to destructor -
Shared libraries can significantly reduce the size of executable files: shared libraries eliminate the need to include commonly used library functions in executable files, but only need to save a copy of this library routine in a storage area accessible to all processes . When the program is executed for the first time or when a library function is called for the first time, use the dynamic link method to connect the program with the shared library function. This reduces the length of each executable file, but adds some runtime overhead. Another advantage of the shared library is that the new version of the library function can be used to replace the old version without relinking and editing the program that uses the library. (Assuming that the number and types of parameters have not changed.) ----> (This needs to be written in the executable file, now in the memory, just take it and link it) Disadvantage: slow
-
In the process of using setjmp and setlongjmp, you need to pay attention to the data non-rollback function like normal goto, and you need to apply volatile to the variables used in the process
-
The child process and the parent process continue to execute the instructions after the fork. The child process is a copy of the parent process. For example, the child process obtains
a copy of the parent process's data space, heap, and stack. Note that this is a copy owned by the child process. The parent and child processes do not share
these storage spaces. If the text segment is read-only, the parent and child processes share the text segment (see section 7.6).
Many implementations now do not make a complete copy of the parent process data segment and heap, because
exec is often followed after fork . As an alternative, the technology of copy-on-write (C opy-On-Write, COW) is used. These areas are
shared by the parent and child processes , and the kernel changes their access permissions to read-only. -
One feature of fork is that all descriptors opened by the parent process are copied to the child process.
The parent and child processes share a file table entry for each same open descriptor. -
Fork will even copy the contents of standard IO such as printf write buffers (those are fully cached) in the parent process before fork (if there is no fflush) to the child process's cache.
-
Forking twice can avoid zombies, provided that the child dies before the grandson, and the grandson receives init instead of the parent.
-
Setuid(500) changes the effective uid to 500 when the program can only be run at 500 when it is not root.
-
[Good experiment for functions such as setuid] https://www.cnblogs.com/robbychan/archive/2013/06/05/3786945.html
-
The child process exit will refresh the standard IO buffer of the parent process, so use _exit
-
In the process of writing myshell, there is a problem that is realized with wait (WHOHANG) & whether it is really put in the background.
No!
If the terminal knows that the child process is running in the background 1. The child process needs to write data to the terminal (you can use stty tostop to prohibit), you can write it out or send a SIGTTOU signal. After disabling, the child process that writes data will be suspended just like the process that reads data from the terminal. The data terminal sends the sigsttin signal. After that, if you need to run it, use the fg command, the terminal sends sigcont to the program, and the program continues to run in the foreground. It can be said that the real background is pause and can be used to continue. However, the myshell experiment just allows the child process and the parent process to run at the same time.