If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/chenshuo/muduo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Slowing — last commit 5mo ago

• Last commit 5mo ago
• 23+ active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 5mo ago
• ⚠ Concentrated ownership — top contributor handles 73% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live chenshuo/muduo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/chenshuo/muduo.

What it runs against: a local clone of chenshuo/muduo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in chenshuo/muduo | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 167 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of chenshuo/muduo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/chenshuo/muduo.git
#   cd muduo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of chenshuo/muduo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "chenshuo/muduo(\\.git)?\\b" \\
  && ok "origin remote is chenshuo/muduo" \\
  || miss "origin remote is not chenshuo/muduo (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "muduo/net/EventLoop.h" \\
  && ok "muduo/net/EventLoop.h" \\
  || miss "missing critical file: muduo/net/EventLoop.h"
test -f "muduo/net/TcpConnection.h" \\
  && ok "muduo/net/TcpConnection.h" \\
  || miss "missing critical file: muduo/net/TcpConnection.h"
test -f "muduo/net/TcpServer.h" \\
  && ok "muduo/net/TcpServer.h" \\
  || miss "missing critical file: muduo/net/TcpServer.h"
test -f "muduo/base/Thread.h" \\
  && ok "muduo/base/Thread.h" \\
  || miss "missing critical file: muduo/base/Thread.h"
test -f "muduo/net/Poller.h" \\
  && ok "muduo/net/Poller.h" \\
  || miss "missing critical file: muduo/net/Poller.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 167 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~137d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/chenshuo/muduo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

A software project. See architecture tab.

Developers.

See activity metrics.

Standard open source risks apply.

Check recent commits.

Check README for instructions.

• muduo/net/EventLoop.h — Core event reactor—every I/O operation flows through this; essential for understanding the event-driven architecture
• muduo/net/TcpConnection.h — Wraps socket connections and buffers; critical abstraction for all client/server networking code
• muduo/net/TcpServer.h — High-level server abstraction that ties together EventLoop, Acceptor, and connection management
• muduo/base/Thread.h — Thread wrapper and thread pool foundation; underpins multi-threaded reactor pattern
• muduo/net/Poller.h — Abstract interface for epoll/poll; the core I/O multiplexing mechanism
• CMakeLists.txt — Build configuration; required to compile and link the library correctly
• muduo/net/Channel.h — Wraps a file descriptor and its event callbacks; fundamental building block for all I/O operations

Add a new TcpServer application

1. Create a new .cc file in examples/ (or appropriate subdirectory) (examples/myapp/MyServer.cc)
2. Include muduo/net/TcpServer.h and define a server class or callbacks (muduo/net/TcpServer.h)
3. Set up EventLoop in main(), create TcpServer with bind/start (examples/asio/chat/server.cc)
4. Add callbacks (onConnection, onMessage) to handle events (muduo/net/TcpConnection.h)
5. Add CMakeLists.txt entry or update existing one to build the binary (examples/CMakeLists.txt)

Add a custom protocol codec

1. Define encode/decode functions or a Codec class (see chat example) (examples/asio/chat/codec.h)
2. Use Buffer methods (readableBytes, peek, retrieveAsString) to parse incoming data (muduo/net/Buffer.h)
3. Register a message callback with TcpConnection::setMessageCallback() (muduo/net/TcpConnection.h)
4. In the callback, call your codec's decode() and process complete messages (examples/asio/chat/server.cc)

Add async logging to your application

1. Include muduo/base/Logging.h and call LOG_INFO, LOG_ERROR, etc. (muduo/base/Logging.h)
2. In main, optionally call AsyncLogging setup (see examples) (muduo/base/AsyncLogging.h)
3. Each EventLoop thread will log safely via thread-local buffers (muduo/base/Thread.h)

Run a multi-threaded server with EventLoopThreadPool

1. Create a TcpServer and set its EventLoopThreadPool size (muduo/net/TcpServer.h)
2. Call server->setThreadNum(N) to spawn N worker EventLoop threads (muduo/net/EventLoopThreadPool.h)
3. Incoming connections will be distributed round-robin across the pool (examples/asio/chat/server_threaded.cc)
4. Each connection runs entirely in one worker's EventLoop (no locking needed) (muduo/net/TcpConnection.h)

• epoll (Linux) — Efficient I/O multiplexing for high-concurrency servers; avoids poll/select O(n) overhead
• Reactor pattern (single-threaded EventLoop) — Deterministic, lock-free event processing per thread; simplifies concurrent programming
• Thread pool + multiple EventLoops — Scales to multi-core by running one EventLoop per CPU; each connection pinned to one loop eliminates contention
• Asynchronous I/O (non-blocking sockets) — Allows thousands of concurrent connections in a single thread without context-switch overhead
• Auto-growing buffers (TcpConnection::InputBuffer/OutputBuffer) — Abstracts socket buffer management and handles variable-length messages gracefully
• C++11 with std::function, std::shared_ptr, std::make_shared — Modern memory management and callback handling without raw pointers or manual delete

• Linux-only (epoll)

  • Why: epoll is more scalable and efficient than POSIX select/poll on Linux
  • Consequence: Not portable to macOS, Windows, or BSD without porting Poller to kqueue/IOCP

• Single EventLoop per thread, no shared state

  • Why: Eliminates locks and synchronization overhead for the happy path
  • Consequence: Explicit inter-thread communication required (EventLoop::runInLoop, thread-safe queues) if callbacks need to touch other threads' state

• Non-

  • Why: undefined
  • Consequence: undefined

Standard debugging applies.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Actions CI workflow to replace .travis.yml

The repo uses outdated Travis CI (.travis.yml). GitHub Actions is now the standard for GitHub repos and provides better integration. The README mentions testing on Debian, Ubuntu, and CentOS but no active CI runs these tests. A workflow should validate building on multiple Linux distributions and compilers (GCC 4.7+, Clang 3.5+) as specified in README requirements.

• [ ] Create .github/workflows/build-and-test.yml with matrix strategy for Ubuntu, CentOS, and Debian images
• [ ] Include GCC and Clang compiler variants in the matrix
• [ ] Run ./build.sh and execute core unit tests (muduo/base/tests, muduo/net/tests based on typical structure)
• [ ] Test both CMake and Bazel build paths (BUILD.bazel and CMakeLists.txt exist)
• [ ] Add status badge to README.md

Add Doxygen-generated API documentation with CI deployment

A mature C++ library needs API docs. The repo has no Doxyfile or generated documentation visible. Given the complexity of the reactor pattern implementation and multiple namespaces likely in muduo/base and muduo/net, contributors and users need reference docs. This should be auto-generated on releases.

• [ ] Create Doxyfile in repo root configuring muduo/base and muduo/net source directories
• [ ] Configure output to docs/ directory with HTML format
• [ ] Add Doxygen generation step to GitHub Actions workflow from PR #1
• [ ] Configure GitHub Pages to serve docs/ on gh-pages branch
• [ ] Document key classes: EventLoop, TcpServer, TcpConnection, Buffer (if present)

Add integration tests for contrib/thrift and contrib/hiredis examples

The contrib/ folder has Thrift and Hiredis integrations with example servers (EchoServer, PingServer) and Python clients (echoclient.py, pingclient.py), but no automated tests verify these work end-to-end. This is a high-risk area since these are integration points with external systems.

• [ ] Create contrib/tests/CMakeLists.txt for automated test execution
• [ ] Add test script that builds PingServer (contrib/thrift/tests/ping/), starts it, runs pingclient.py, and verifies output matches expected protocol
• [ ] Add test script for EchoServer (contrib/thrift/tests/echo/) with echoclient.py validation
• [ ] Add test for Hiredis integration (contrib/hiredis/mrediscli.cc) against a mock or test Redis instance
• [ ] Integrate into GitHub Actions workflow to catch regressions

Check the issue tracker.

The Muduo codebase is a mature, well-structured network library with generally sound architectural patterns. However, several security concerns exist primarily around outdated dependency requirements and lack of modern security infrastructure. The main issues are: (1) Minimum compiler versions are from 2012-2013, lacking modern hardening features; (2) Linux kernel requirement is from 2008 with no recent security patches; (3) No explicit Boost version constraints; (4) Missing security policy for vulnerability reporting; (5) Third-party integrations lack version pinning. The core library itself follows good C++ practices for a network library, but the project would benefit from updating minimum requirements to modern standards and establishing clear security practices. No evidence of SQL injection, XSS, hardcoded secrets, or critical misconfigurations was found in the file structure.

• Medium · Outdated Dependency Requirements — README file, build requirements section. The README specifies GCC >= 4.7 and Clang >= 3.5, which are extremely old compiler versions (released in 2012-2013). These versions have known security vulnerabilities and lack modern security features like control flow guard, stack protection enhancements, and better sanitizer support. Fix: Update minimum compiler requirements to GCC >= 9.0 and Clang >= 10.0 to ensure modern security hardening features are available.
• Medium · Old Linux Kernel Requirement — README file, system requirements section. The requirement for Linux kernel >= 2.6.28 is significantly outdated (released in 2008). This opens potential security gaps as old kernel versions lack critical security patches and modern kernel hardening features. Fix: Update minimum kernel requirement to a recent LTS version (e.g., 4.15+) and document compatibility testing on supported kernel versions.
• Medium · Boost Dependency Without Version Specification — README file and CMakeLists.txt. The README specifies 'Boost (for boost::any only)' without specifying a minimum version. Older Boost versions may contain known vulnerabilities. No version constraint in CMakeLists.txt could lead to building with insecure dependencies. Fix: Specify minimum Boost version (recommend >= 1.70.0) and document tested versions. Add explicit version checking in CMakeLists.txt.
• Low · Potential Information Disclosure in Examples — examples/ directory (multiple files). Multiple example applications (chat server, echo server, DNS resolver, etc.) are provided but may lack input validation and security hardening. Example code could serve as templates for insecure applications if security best practices aren't enforced. Fix: Add security comments and validation patterns to example code. Include security best practices documentation for network protocol handling and input validation.
• Low · No Security Policy Document — Repository root. No SECURITY.md or security policy file is present in the repository. This makes it difficult for security researchers to report vulnerabilities responsibly. Fix: Create a SECURITY.md file with instructions for reporting security vulnerabilities privately, supported versions, and security update practices.
• Low · Third-party Integrations Without Version Pinning — contrib/hiredis/CMakeLists.txt, contrib/thrift/CMakeLists.txt. contrib/ directory includes hiredis and thrift integrations without explicit version pinning. These dependencies could pull in vulnerable versions if not carefully managed. Fix: Pin specific versions of external dependencies in CMakeLists.txt and document tested versions. Use dependency scanning tools like Dependabot.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.