Block on the socket until the rest of the command arrives, since returning with a partial parse wastes the read and the kernel buffer already holds the bytes, so the wait would be short.

Discard the partial bytes and let the client retransmit the whole command; RESP framing is designed for that.

The loop should return to polling or other ready callbacks after preserving buffered bytes; readiness was useful even though no full command was produced.

Close the connection, because a read event that yields no complete command indicates a protocol violation.

A long command monopolizes the single command execution thread, so unrelated clients wait until control returns to the event loop.

The kernel stops accepting TCP packets for other clients while one command is running on the server.

Latency rises because the long command holds the global keyspace lock that every reader has to wait on.

It only affects clients sharing that connection; other connections are handled by parallel loop iterations, each iteration picking up wherever the previous one left off.

Snapshot triggers and AOF rewrites belong in time events, but timeout checks and rehash steps must run inside command handlers to stay accurate.

Deadline sampling, cron-style maintenance, timeout checks, incremental rehash steps, and background bookkeeping fit time events better than individual handlers.

Time events should take over command parsing for slow clients, freeing file events to serve the fast ones.

Nothing belongs in time events in a single-threaded design, because periodic work would freeze the event loop.

Thread-per-client pays mostly in stack memory, while the event loop pays mostly in a higher system-call count.

The event loop pays in locking because its callbacks share state, while threads avoid races since each owns its client, which is why reactor frameworks ship with so many mutex utilities.

Both pay identical costs in practice, differing only in the portability of the polling API they sit on.

Thread-per-client pays in locking and shared-state races, while an event loop pays in nonblocking IO, buffering, and avoiding long callbacks.

File descriptor readiness means the OS says IO might proceed; application progress means the Redis layer actually parsed, executed, flushed, or completed work.

They are the same thing, because epoll only reports readiness once a complete request is available to parse — that is what the level-triggered mode guarantees to applications.

Readiness describes writes and progress describes reads, tracked by the loop with separate descriptors.

Progress is the kernel's view of its socket queues, while readiness is the application's view of parsed commands.