The ultimate guide to senior engineering interviews. Strategies developed by FAANG engineers on Python concurrency, multithreading, monitors, and event loops. Prep faster for top company questions.

Concurrency in Python is one of the most complex and advanced topics brought up during senior engineering interviews. Knowledge of concurrency and multithreading can put interviewees at a considerable advantage. This course lays the foundations of advanced concurrency and multithreading and explains concepts such as Monitors, Event Loops and Deferred Callbacks in depth. It also builds simple and complete solutions to popular concurrency problems that can be asked about in interviews like the Reader-Writer Problem and the Dining Philosopher Problem. While prior knowledge of concurrency is not required to follow through with this course, familiarity with the very basic Python would be helpful.

Python Concurrency for Senior Engineering Interviews

<div class="card">
 # Spawn 
 <div class="ans">
In the previous section, we discussed how we could create processes using fork as the start method. However, fork comes with shortcomings of its own and may not be what we want. The next option available to create a process is the spawn method.

## exec system call
In order to understand spawn, we'll examine the exec family of system calls. When you issue an ls or a find command in your terminal, the shell first forks itself and then invokes one of the variants of the exec family of system calls. Briefly, an exec call transforms the calling process into another. The program in the calling process is replaced with another program and is run from the entry point. Realize the distinction between a program and a process as it matters in this context. The program is just a set of instructions and data that is used to initialize a process. Using exec, the running process loads a program (instructions and data) and replaces its own program with the loaded one and starts execution.

Both fork and exec can be called independently and need not be called in succession. For instance, a process that is ending can simply call exec and start another program rather than forking itself. Similarly, a process listening on a socket may want to fork itself to let the child process deal with a received request while it goes back to listening. But the usual way to create a new process in the Unix world is to first fork in the parent process and then exec in the child process. The child process's PID doesn't change and the parent process can wait for the child process to finish before resuming execution.

Remember, forking produces two processes, whereas exec loads an executable in the existing process's address space. The current executable image is replaced with another one loaded from an executable file.

## spawn call

With the above background, it is easier to explain the "spawn" start method. Spawn is essentially a combination of fork followed by an exec (one of its variants) system call. Depending on the platform, posix_spawn system call may also be used. posix_spawn is roughly a combination of fork and exec with some optional housekeeping steps between the two calls. 

This solves the problem we encountered with fork start method. The module state isn’t inherited by a child process, rather it starts from scratch. A new python interpreter process is created and the child doesn't inherit any resources from the parent process other than those required to execute the specified callable target.

Note that spawning a process is slower than forking a process. When a child process is spawned anything imported at the module level in the __main__ module of the parent process gets reimported in the child. Consider the example below. If you change the start method to "spawn" on line 14, you'll see that the print messages in the imported modules are printed twice. Once when the main process runs and once when the child process runs. However, running the snippet with "fork" as the start method will only have the modules imported once for the main process.

</div>
</div>

<div>
 # Spawn 
 <div>
In the previous section, we discussed how we could create processes using fork as the start method. However, fork comes with shortcomings of its own and may not be what we want. The next option available to create a process is the spawn method.

## exec system call
In order to understand spawn, we'll examine the exec family of system calls. When you issue an ls or a find command in your terminal, the shell first forks itself and then invokes one of the variants of the exec family of system calls. Briefly, an exec call transforms the calling process into another. The program in the calling process is replaced with another program and is run from the entry point. Realize the distinction between a program and a process as it matters in this context. The program is just a set of instructions and data that is used to initialize a process. Using exec, the running process loads a program (instructions and data) and replaces its own program with the loaded one and starts execution.

Both fork and exec can be called independently and need not be called in succession. For instance, a process that is ending can simply call exec and start another program rather than forking itself. Similarly, a process listening on a socket may want to fork itself to let the child process deal with a received request while it goes back to listening. But the usual way to create a new process in the Unix world is to first fork in the parent process and then exec in the child process. The child process's PID doesn't change and the parent process can wait for the child process to finish before resuming execution.

Remember, forking produces two processes, whereas exec loads an executable in the existing process's address space. The current executable image is replaced with another one loaded from an executable file.

## spawn call

With the above background, it is easier to explain the "spawn" start method. Spawn is essentially a combination of fork followed by an exec (one of its variants) system call. Depending on the platform, posix_spawn system call may also be used. posix_spawn is roughly a combination of fork and exec with some optional housekeeping steps between the two calls. 

This solves the problem we encountered with fork start method. The module state isn’t inherited by a child process, rather it starts from scratch. A new python interpreter process is created and the child doesn't inherit any resources from the parent process other than those required to execute the specified callable target.

Note that spawning a process is slower than forking a process. When a child process is spawned anything imported at the module level in the __main__ module of the parent process gets reimported in the child. Consider the example below. If you change the start method to "spawn" on line 14, you'll see that the print messages in the imported modules are printed twice. Once when the main process runs and once when the child process runs. However, running the snippet with "fork" as the start method will only have the modules imported once for the main process.

</div>
</div>

This lesson discusses the alternative to forking processes, which is spawning them.

The Basics

Threading Module

Multiprocessing

Concurrent Package

Async.io

Global Interpreter Lock

Interview Practise Problems

The End

Spawn

Spawn

exec system call