Comments (9)
The parsing is happening here, and that code is run inside the hyper acceptor
task.
We can't assume the user of the library wants to spawn a new task per connection (most reasonable servers would likely want to use a task pool with a limit).
What if a handler were to spawn a task before calling incoming.next()
. That should move the parsing into a separate task, right? Can that be safely/easily done? I haven't looked too hard.
from hyper.
It would require Arc<Mutex<Incoming>>
but should work, so that is one workaround.
from hyper.
Alternatively, the Incoming
could return some sort of "request/response" future, so that once it's been passed to a destination task, the parsing could happen there.
from hyper.
The more I think about it, the more I like returning a Future<(Request, Response<Fresh>)>
.
from hyper.
That requires allocating a new proc and task for each incoming Request, which basically defeats the purpose.
Maybe we could work around the proc when unboxed closures are moved into libs, but we would still need a new task.
from hyper.
No it doesn't. There is Future::from_fn
, which does not execute on a new task.
from hyper.
This allows the parsing to be deferred until the Future is on whichever task will be handling the Request, and reduces the overhead of an Arc and Mutex.
from hyper.
You are right, I was thinking of Future::spawn
. We still have to allocate for a proc()
, but that could be avoided if we defined our own Future type which stored F: FnOnce() -> T
or a more specialized type that stored the NetworkStream
and an fn(Box<NetworkStream>) -> (Request, Response<Fresh>)
so that we get static dispatch and can avoid unnecessary allocation.
Basically we should do the minimum possible work between "get a connection" and "yield to incoming.next", then allow all further processing to be done with the returned handle, so it can be done in another task.
The contention we'd get from locking/unlocking a mutex at 100s of concurrent connections will almost definitely hurt a lot.
Related data point: using a TaskPool in Iron instead of regular spawn sped up Iron by 80%.
from hyper.
fixed with #110
from hyper.
Related Issues (20)
- About h2 server config `DEFAULT_SETTINGS_MAX_HEADER_LIST_SIZE`
- Very slow body read times on hyper 1+ HOT 3
- How to limit the size of request headers?
- I hope the code can be modified as follows HOT 3
- `Upgraded::downcast_ref` is unusable with `hyper_util::server::conn::auto` HOT 4
- Is it possible to add a server demo to CAPI? HOT 1
- The script that generates the header file is not available HOT 2
- I see that in client.c in the C API, select is used for socket listening. Does this mean the C API does not support Tokio?
- hyper::Error(User(DispatchGone) on client request using tonic HOT 3
- Custom response header value is a copy of custom request header value HOT 2
- [Not a bug] internal error: h2 protocol error: http2 error: stream error sent by user: unexpected internal error encountered
- No `Connection: close` on HTTP1 Connection Drain HOT 1
- hang when client receives header response that's too big in http2
- hyper-util: expose connection info on whether it's reused from the pool or newly established HOT 3
- Poor performance in http/1.1 with many socket connections HOT 7
- Documentation: Lack of a Quick Start/Basic Usage section HOT 2
- cargo bench fails to compile HOT 5
- Allow clients to send data before headers are received HOT 9
- connection error: user body write aborted: early end, expected xxxx more bytes HOT 1
- Test `test_try_send_request` is flaky
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 hyper.