Comments (2)
@seanmonstar any pointers? My use cases are:
- Socket accepting. It's well covered by
rotor_stream::Accept
, and even if you implement it by hand I believe it's better to accept next connection inspawned()
rather than wait for next level-triggered event. While is it the best way or not depends on many things, I want it to be a deliberate decision, rather than default. - Establishing client connections. If you have a connection pool state machine which spawns client connections, there is nothing that ensures that maximum single connection can be created per wake up of connection pool.
- The only case with
ok()
I have is inrotor-carbon
, which is a monitoring protocol, which have an inherently single connection
The (3) looks more like exception rather than rule. There are many more cases that does have unreachable!()
in spawned
rather than ok()
.
The timeout
and wakeup
are also deliberately non-defaulted. In my perspective, almost nobody will use rotor::Machine
in end-user application. It's more suited for protocol writers. And for writing another protocol on top of rotor:Machine
you must deliberately choose if you want to skip timeouts and wakeups. Most protocols should provide timeout
and wakeup
in the handler based on top of it, so user can use asynchronous things in handler. Off the top of my head, I think only unidirectional protocols might ignore the events.
The spawned
case is also similar, only protocol writers will need to write it, not the protocol users, so I believe it is better to enforce a decision. Ignoring the is easy. But unawareness of these things may lead to ugly workarounds.
Does it make sense?
from rotor.
Yes, that makes sense. I agree, I don't expose Machine
to a user, but instead a server::Handler
that is ignorant of the internals.
from rotor.
Related Issues (16)
- How to wakeup a protocol? HOT 6
- Communication between machines and the world outside the MIO event loop HOT 11
- Want to be on Rusty Radio? HOT 3
- Rust Nightly Error: Found value used as a type HOT 2
- A way to identify Timeouts HOT 12
- Response structure doesn't permit correct use of edge polling HOT 3
- Can't import rotor::Time HOT 2
- Expose mio::Handler.tick HOT 1
- Deferring work to another protocol HOT 2
- Shutdown on last machine closing? HOT 6
- Support for DPDK HOT 1
- UdpSocket is never writable HOT 5
- Add Machine to Running Loop HOT 3
- Comparison with tokio-core
- Is Rotor still in active development or stopped ? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rotor.