Simply put, threads cannot sleep waiting for the vlib memory api main input queue to drain. If, say, thread i (i !=0) fills the vlib api main input queue with rpc requests - and then blocks trying to add another request - the game is over.

RPC's attempt a barrier synchronization, which fails with Pr =

because thread i is in a mutex/condvar sleep.

We need to desk check every place which calls vl_msg_api_alloc_as_if_client(...), looking for variations on this theme.