[zeenix]

A client that stops reading its socket froze the whole bus. Each connection has one task that reads a message from its client and forwards it before reading the next, and a send only returns once the destination's socket has taken the whole message. So such a client held up everyone who sent to it, the bus itself included. Once a broadcast of the bus waited on it, holding the read locks of the name registry and the peers, the next client to connect waited for the write lock of the peers. zruntime's RwLock prefers writers, so every forward after that waited too.

With a client subscribed to the bus's signals stopped by SIGSTOP (gdbus monitor under kill -STOP), the bus stopped answering anyone after 66 clients had come and gone, calls between clients that were connected all along included, until the frozen client was let go. dbus-daemon and dbus-broker answered all 1500 calls of the same test. The same mechanism deadlocked a benchmark where 100 proxies on one zbus 4.3 connection call a service on that same connection.

The change

• Each client gets a queue of the messages on their way to it, and a task that writes the queue to its socket. Forwarding to a client only queues the message, so it never waits on the client's socket. Locks are held only while queuing.
• Messages for the bus itself still go straight to its connection and may wait for room, which holds back a client that floods the bus. That is safe because the bus never waits on a client any more, and such a message is only sent once the locks are released, since the bus may need them to make room.
• A queue always takes one message, however big, but a client whose queue would hold more than 127 MiB (dbus-daemon's default max_outgoing_bytes) gets disconnected, so that a client that never reads can't make the bus hold its messages for good. The constant could come from the config's <limit> later; busd ignores those for now.
• A message with file descriptors, for a client that didn't negotiate passing them, is dropped, as on main, and the messages after it still go. Any other failure to write to a client gets it disconnected, so that the bus doesn't keep a client that gets nothing, along with its names.
• Passing file descriptors is part of the write, and Linux passes at most 253 (SCM_MAX_FD) in one write, while zbus passes all those of a message with its first write. So passing on a message with more always fails, and would get its recipient disconnected: any client could get any other one disconnected. The second commit disconnects the client that sends such a message instead, as dbus-broker 35 does. dbus-daemon 1.14.10, with its stock session configuration, disconnects the sender of a message with 17 or more.
• zruntime's mpmc feature provides the queue.
• A known limit: a client that shuts its socket down for writing while a message is on its way to it, and never reads, leaves that message's writer waiting, and with it the client's socket and queue, until busd exits. Before this change, the task of whoever sent the message got stuck the same way, holding up its client too. Having the writer stop when the last handle of its queue is dropped would fix it.

Testing

• tests/stalled_client.rs adds five tests:
  • stalled_client: a client that reads nothing while subscribed to every signal gets 2 MiB of signals, and the bus must still answer RequestName/ReleaseName and a new client.
  • overflowing_client: signals of 8 MiB go to such a client until it gets disconnected.
  • client_without_fds: a client on a socket that zbus doesn't negotiate passing file descriptors over gets a signal with one, and must still get the reply to its next call.
  • unwritable_client, on Linux only, where writing to a socket fails once its peer shuts it down for reading: a client does that, gets a signal, and must get disconnected.
  • too_many_fds, on Linux only: a client sends another one a message with 253 file descriptors, which must get to it, and then one with 254, for which the bus must disconnect the sender, and not the recipient.
• The first two time out against main, the next two fail if the writer stops at a failed write without disconnecting the client, and the last one fails without the second commit. All five pass, within about a second, in each of 320 runs, with other runs going at the same time.
• cargo test on stable and nightly, cargo +nightly fmt --all -- --check, cargo clippy --all -- -D warnings, with and without default features and with --all-targets, cargo check --tests --target aarch64-apple-darwin, the builds of CI with RUSTFLAGS=-D warnings and the gimoji commitlint pass, on each commit. The branch merges cleanly with zeenix/busd fix-monitor-broadcast and match-rule-fixes, and all tests pass with the three merged.
• The frozen-subscriber test (in Refresh the results on zbus 6, and add a look into a busd stall zeenix/dbus-bench#3) now gets the same results as dbus-daemon and dbus-broker: all 1500 calls answered, and 8 of 8 calls between long-lived clients.
• The benchmark client on zbus 4.3 that deadlocked in its shared-connection phase now finishes it, in all 3 runs (11.1 to 11.8 s).

Cost

60 interleaved rounds of the dbus-bench benchmark (zbus 6 client) on a 4-vCPU VM, against main (a982812), with Mann–Whitney U p-values:

Metric	main	this branch
Single client	0.139 s	0.139 s (p = 0.65)
20 clients	0.684 s	0.694 s (p = 0.37)
Broker CPU time, 20 clients	0.480 s	0.490 s (+2.1%, p = 0.0008)
Peak memory	4826 KiB	4896 KiB (+1.5%, p < 0.0001)

Generated by Claude Opus 5.5 (claude-opus-5-5).

🤖 Generated with Claude Code

[zeenix]

Changes requested.

Review by Codex on behalf of @zeenix.

One blocking regression: an unsupported file-descriptor message permanently disables delivery to an otherwise live client.

[zeenix]

No actionable findings.

Review by Codex on behalf of @zeenix.