-
Notifications
You must be signed in to change notification settings - Fork 0
Add WireframeServer skeleton #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add WireframeServer skeleton #6
Conversation
Reviewer's GuideIntroduces a Tokio-based WireframeServer skeleton with per-worker WireframeApp factories and graceful Ctrl+C shutdown, exports the new server module, adds async runtime dependencies, and updates the roadmap documentation to describe the startup workflow. Sequence Diagram for WireframeServer Startup and ShutdownsequenceDiagram
actor User
participant Main as "WireframeServer.run()"
participant TokioRuntime
participant Worker as "Worker Task"
participant Listener as "TcpListener"
participant SignalHandler as "Ctrl+C Signal Handler"
User->>Main: Call run()
activate Main
Main->>Listener: TcpListener::bind(addr)
Listener-->>Main: listener instance
Main->>Main: Create shutdown_tx broadcast channel
loop For each worker (self.workers)
Main->>Main: shutdown_rx = shutdown_tx.subscribe()
Main->>TokioRuntime: tokio::spawn(worker_logic with app_factory, listener_ref, shutdown_rx)
TokioRuntime->>Worker: Start task
activate Worker
Worker->>Worker: app = app_factory()
Worker->>Worker: Enter tokio::select! loop (listen on Listener.accept() & shutdown_rx.recv())
end
Main->>SignalHandler: Listen for tokio::signal::ctrl_c()
deactivate Main
User-->>SignalHandler: Sends Ctrl+C Signal
activate SignalHandler
SignalHandler-->>Main: Notify Ctrl+C received
deactivate SignalHandler
activate Main
Main->>Worker: shutdown_tx.send(()) (broadcast to all workers)
activate Worker
Worker->>Worker: Receives shutdown via shutdown_rx, breaks select! loop
Worker-->>TokioRuntime: Task terminates
deactivate Worker
Main-->>User: run() returns Ok(())
deactivate Main
Class Diagram for WireframeServerclassDiagram
class WireframeServer~F~ {
<<struct>>
-factory: F
-addr: Option<SocketAddr>
-workers: usize
+new(factory: F) WireframeServer~F~
+workers(count: usize) WireframeServer~F~
+bind(addr: SocketAddr) Result~WireframeServer~F~~~
+run() async Result~()~
}
class WireframeApp {
%% Existing component, details omitted as it's referenced by the factory F
}
WireframeServer~F~ ..> WireframeApp : "factory F produces instances of"
class SocketAddr
class Result~T~
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Warning Rate limit exceeded@leynos has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 1 minutes and 3 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (2)
WalkthroughThe changes introduce a new Tokio-based asynchronous server implementation, Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant WireframeServer
participant WorkerTask
participant WireframeApp
participant OS
User->>WireframeServer: new(factory)
User->>WireframeServer: workers(count)
User->>WireframeServer: bind(addr)
User->>WireframeServer: run()
WireframeServer->>OS: Bind TCP listener
loop For each worker
WireframeServer->>WorkerTask: Spawn async task
WorkerTask->>WireframeApp: Create via factory
WorkerTask->>OS: Accept TCP connections
end
OS-->>WireframeServer: Ctrl+C signal
WireframeServer->>WorkerTask: Broadcast shutdown
WorkerTask->>OS: Stop accepting connections
Possibly related PRs
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @leynos - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟡 General issues: 3 issues found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Nitpick comments (2)
Cargo.toml (1)
9-11
: Restrict Tokio’s default features to curb compile-time bloat.Tokio pulls in many sub-crates by default. When you already list the concrete features you need (
net
,signal
,rt-multi-thread
,macros
,sync
), adddefault-features = false
to avoid accidentally compiling unused extras such as IO-URING or time.-tokio = { version = "1", features = ["net", "signal", "rt-multi-thread", "macros", "sync"] } +tokio = { version = "1", default-features = false, features = ["net", "signal", "rt-multi-thread", "macros", "sync"] }src/server.rs (1)
75-97
: Minor concurrency issues inside worker loop.
- Using a broadcast buffer of
1
risks discarding the shutdown message if tasks lag.- Accept-error handling only logs; a repeated fatal error (e.g. EMFILE) causes a tight loop. Consider exponential back-off or bubbling the error.
_app
is instantiated but never used; if its drop impl does clean-up, moving it inside the accept loop might be safer.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
Cargo.lock
is excluded by!**/*.lock
📒 Files selected for processing (4)
Cargo.toml
(1 hunks)docs/roadmap.md
(1 hunks)src/lib.rs
(1 hunks)src/server.rs
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: coverage
🔇 Additional comments (2)
src/lib.rs (1)
3-3
: Publicly exporting theserver
module looks good.The new module is now discoverable to downstream crates and matches the crate’s layering.
docs/roadmap.md (1)
20-24
: Roadmap update is consistent with the implementation.Tick-marking
WireframeServer
here mirrors the new code – no issues.
…ads` Docstrings generation was requested by @leynos. * #6 (comment) The following files were modified: * `src/server.rs`
Note Generated docstrings for this pull request at #7 |
…ads` (#7) Docstrings generation was requested by @leynos. * #6 (comment) The following files were modified: * `src/server.rs` Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Summary
WireframeServer
Testing
cargo fmt
cargo clippy -- -D warnings
cargo test
markdownlint docs/roadmap.md
nixie docs
https://chatgpt.com/codex/tasks/task_e_684a273f985c8322a9734a0131abcf4c
Summary by Sourcery
Add a skeleton for a new async server to host WireframeApp instances using Tokio, configure it for multi-threaded workers, and hook in graceful shutdown. Update project structure and docs accordingly.
New Features:
Build:
Documentation:
Summary by CodeRabbit