When implementing a server, a programmer is faced with a dilemma as to whether to use threads or processes to handle requests. Both have advantages and disadvantages. From its very inception, MySQL has used threads. In this chapter we discuss the rationale, strengths and weaknesses, and implementation of thread-based request handling in the MySQL server.
Perhaps the most important difference between a process and a thread is that a child thread shares the heap (global program data) with the parent, while a child process does not. This has a number of implications when you are deciding which model to use.
Threads have been implemented in programming libraries and operating systems industry-wide for the following reasons:
Reduced memory utilization. The memory overhead of creating another thread is limited to the stack plus some bookkeeping memory needed by the thread manager.
No advanced techniques required to access server-global data. If the data could possibly be modified by another concurrently running thread, all that needs to be done is to protect the relevant section with a mutual exclusion lock or mutex (described later in this chapter). In the absence of such a possibility, the global data is accessed as if there were no threads to worry about.
Creating a thread takes much less time than creating a process because there is no need to copy the heap segment, which could be very large.