uWSGI主进程与工作进程如何通信？底层机制是什么？

Awesome question! Let’s break down exactly how uWSGI’s master and worker processes communicate, including whether signals are involved and the nitty-gritty of the underlying mechanisms.

First, let’s recap your command and output for context:

Your uWSGI Command #

uwsgi --master --worker 4 --http-socket 0.0.0.0:8001 --wsgi-file ./examples/flaskpost.py

Command Output #

spawned uWSGI master process (pid: 38968)
spawned uWSGI worker 1 (pid: 38969, cores: 1)
spawned uWSGI worker 2 (pid: 38970, cores: 1)
spawned uWSGI worker 3 (pid: 38971, cores: 1)
spawned uWSGI worker 4 (pid: 38972, cores: 1)

uWSGI Master-Worker Communication: The Details #

1. Signals Are Used for Core Control Actions #

Yes, signals are a critical part of the master-worker control flow. The master sends standard Unix signals to workers to trigger specific behaviors, like:

• Graceful reloads (SIGUSR1): Workers finish their current requests before exiting, then the master spawns fresh replacements
• Immediate shutdown (SIGINT or SIGKILL): Workers stop processing immediately
• Pausing/resuming work (SIGSTOP/SIGCONT): Temporarily halt or restart worker activity
• Detecting crashed workers: The master uses waitpid() to monitor worker exit statuses (tied to signal handling for child process termination) and automatically spawns new workers if any crash

For example, if you run kill -SIGUSR1 38968 (sending SIGUSR1 to your master PID), you’ll see the master cycle out the old workers and spawn new ones.

2. Shared Memory & Unix Sockets for Data/Task Coordination #

While signals handle simple control commands, more complex communication relies on two key tools:

• Shared Memory: uWSGI uses OS-level shared memory segments to store global state (like performance metrics, cached data, or loaded configurations). All workers can read (and safely write to, via synchronization) this data—this is way faster than network-based IPC for frequent, small data access.
• Unix Domain Sockets: These local, low-overhead sockets are used for structured communication between the master and workers. For instance, the master might send configuration updates or task instructions through a dedicated socket that workers listen to. Unlike TCP sockets, Unix sockets don’t have network overhead since they’re restricted to the local machine.

3. Underlying Mechanism: Built on Unix IPC Primitives #

uWSGI’s communication layer is built directly on standard Unix system calls and IPC primitives:

• Signal handling: Workers register signal handlers for specific signals sent by the master. The OS handles delivering these signals and triggering the worker’s pre-defined actions.
• Shared memory: Uses shmget/shmat system calls to create and attach to shared memory regions. Mutexes or semaphores (OS synchronization tools) prevent race conditions when multiple workers access shared data.
• Unix sockets: Uses socket() with the AF_UNIX family, paired with send()/recv() calls to pass structured messages between processes.
• Worker monitoring: The master uses waitpid() to track worker status. If a worker exits unexpectedly, the master detects this via the exit status and spawns a replacement immediately—this is how uWSGI maintains high availability.

内容的提问来源于stack exchange，提问作者WeizhongTu