AbletonOSC's OSC server uses a non-blocking UDP socket to drain all queued messages per tick without blocking Live

OSCServer in AbletonOSC uses a non-blocking UDP socket (setblocking(0)) and a 65536-byte recv buffer. The process() method loops calling recvfrom() until EAGAIN/EWOULDBLOCK is raised (meaning the queue is empty), draining all queued messages in one tick. This is necessary because Live’s Python runtime cannot use threads — a blocking recvfrom() or a loop without an escape would stall Live’s audio engine. The server dynamically updates its reply address to the most recently-seen client IP, meaning the last client to send a message is the one that receives push notifications.

Examples

The tick loop: while True: data, addr = socket.recvfrom(65536); parse_bundle(data, addr). Exits on EAGAIN. Edge case: if two clients send messages, push replies go to whichever sent last.

Assessment

Why does AbletonOSC use a non-blocking socket instead of a blocking one? What happens if two different machines both send OSC messages to AbletonOSC — which one receives the beat-listener push replies?