Jupyter Kernel ZeroMQ Message Serialization Under Concurrent Client Requests

Goal

Determine whether Jupyter kernels can safely serialize concurrent requests from multiple clients through a single ZeroMQ input channel without output interleaving or protocol ordering violations.

Constraints

Each kernel maintains one message handler and processes incoming messages sequentially over a single ZeroMQ channel. The Jupyter protocol does not provide native request-level concurrency control. Behavior varies across Python, R, and Julia kernel implementations, and JupyterLab may queue messages differently than the classic Notebook.

Uncertainty

Protocol-level ordering is preserved, but processing may interleave unexpectedly. The iopub channel broadcasts all output, potentially causing client-side race conditions where results from separate requests appear mixed. It is unclear whether serialization holds under high concurrency or where the kernel manager implements the queue.

Questions

1. Does the Jupyter kernel's ZeroMQ message handler guarantee strict request-response isolation when multiple clients send concurrent long-running commands?
2. Where in the Jupyter kernel manager source is the message queue that serializes concurrent requests?
3. Do Python, R, and Julia kernel implementations differ in concurrent message queue handling?