Why are blocking socket calls a problem on an MCU, and what are the alternatives?

By default socket calls block: recv sleeps until data arrives, connect until the handshake finishes or times out, accept until a client connects. On a desktop with an OS and threads, a blocked thread just yields the CPU to others, so it's fine. On a single-threaded bare-metal main loop, a blocking call freezes the entire program, no other tasks run, no sensors are serviced, and critically the watchdog may not get kicked, so the device resets. The alternatives: set sockets non-blocking (O_NONBLOCK), so calls return immediately with EWOULDBLOCK if they'd block and you poll them as part of your loop; use select/poll to wait on multiple sockets at once with a timeout and service whichever is ready, which scales to several connections without threads; or use the stack's event/callback API (lwIP's raw or netconn APIs) where the stack invokes your callback when data arrives or a connection event occurs, fitting an event-driven bare-metal or RTOS design with no blocking at all. Under an RTOS you can also dedicate a task to a blocking socket so only that task blocks while others run. The rule is to never let a blocking network call stall a real-time loop, choose the concurrency model (non-blocking + select, callbacks, or a dedicated task) that matches your scheduler.