RunLoop notes (reprinted from Noah)

In mind there is an abstract concept, an abstract model. Consider the following questions:
1, how does a thread work, and when all tasks are performed, it hangs up.
2, how did the event (event) receive? For example, I/O events, how do events pass after the user touches the screen? How do threads capture these events? What’s the difference between
3, GUI program, or CLI program?

The program has only one thread. When the function return, the thread is hung. Because it is the only thread, the process is hung.

Int main (int, argc, char, *argv[]) {printf ("Hello world"); return 0;}

Also, what do you know (user states), User, mode, and (kernel) Kernel mode? Both of them belong to the knowledge of operating system. Here, a more practical example will be easier to understand. For example, you want to write a string into a file. Steps are

StringToWrite = Hello, world, path = /my_file.txt, writeTo (path, stringToWrite)

1, construct a string variable – user mode
2, construct the target address – user mode
3 configuration file in the corresponding directory with the standard library for the current language, the string will be written into the – user mode – > nuclear state

When the program is executing to a certain section, the program calls a system call function that tells the operating system kernel to do something that only the operating system kernel has permission to do, and the local program can not do it. The I/O operation is typical of system call. The user state enters the kernel state through the system call, when the writeTo function is blocked because it needs to wait for the operation kernel to return the result, and the I/O operation is very time consuming. This is a typical synchronization program, and writeTo needs to wait for the operating system kernel to return the result to return, where the thread is blocked directly.

Smart you will probably want to work here, this program can only do what the operating system, resulting in a waste of resources, CPU, because this is not a time-consuming operation operation, but only I/O access only, so CPU is idle. What should be done in the light of the principle of maximizing the use of CPU resources? Divide a thread out, put writeTo in, no, the main thread will not be blocked. But did you find one point? Even though we don’t want to wait, we also need to know the result of writeTo. What can I do about it? Communication between threads… But what? Think about it. The following wording is unable to communicate between two threads.

Main {thread = Thread (threadEntry) thread.run () return} threadEntry {stringToWrite = Hello world = /my_file.txt 'writeTo' (path, stringToWrite) return} path

There is a simpler way to save the result in a global variable so that all two threads can access it. Declare a variable result outside the two thread entry function and fill in the result of writeTo.

ThreadEntry {stringToWrite = Hello, path = world = /my_file.txt = writeTo (path, stringToWrite) return} result

Well, the last thing you need to think about is the same. Look at Runloop again and you’ll find out… That’s the way it is. The
question is, how do we get the value of result in the main function of the main thread entry?

Main {thread = Thread (threadEntry) thread.run (if result) {/ / if write here, result have not been assigned return}}

Extended reading, digression… You can skip
and talk about Runloop. In fact, there’s a very similar mechanism in node.js, called EventLoop, the event loop. Node.js is an executive platform environment…. The JS code is executed. It is single threaded.. But almost all I/O operations are asynchronous. Unlike Apache,
does not create new threads to respond to the request after the user’s request is received. Node. Apache will, each request corresponds to a thread, so the thinking of writing PHP is very simple, because all operations are synchronous, and the code sentence by sentence will be executed in sequence. If you need to check the data from the database after execution of a paragraph, the thread is blocked directly until the database returns the data. As in the example above, there is no thread out of the child. The disadvantage of this approach is obvious, if a large number of user requests, so you need a large number of threads, assuming that these requests are from the database search data, then CPU will be a serious waste of resources, because the I/O operation does not need too much CPU resources. A large number of threads also take up a lot of memory… Node is a wonderful thing. It has only one thread. In order to handle multiple requests, it must have a none-blocking mechanism. If every request has to be blocked, users don’t blow it up. The model of
node is like this, receiving requests through an entry function, and then executing for a while until the I/O operation is necessary… Node throws the callback function and a task identifier into a queue to wait and return immediately. At this point, node can continue to process second requests until I/O is needed and continue to the queue… When the first I/O operation is complete, node moves the combination of the identification and callback functions to… Waiting call in event queue.

There is a loop mechanism in node, where each loop node goes through the elements in the two queue, determines which element the corresponding I/O request is complete, and then puts it in the event queue. The event queue is called to call the corresponding callback function within the element…