Dynamic/structured profiling & visualization for sync and async operations
🚰 binary data "streams+" via data producers, data consumers, and pull flow.
Combine a reader + writer into a duplex of Read + Write
Fishrock123/beautify-benchmark 32
Beautify Benchmark.js's output into readable form.
My first actually published game, developed in late 2017 as an easter egg within N|Solid.
It's pronounced like "IO" would be in English
Better build and test infra for Node.
Highly configurable status indicators for your node.js cli.
Rust library for sending data to Honeycomb
startedJille/raft-grpc-example
started time in 2 hours
issue openedhttp-rs/tide
The example at https://docs.rs/tide/0.15.0/tide/ listens on port 8080, but the curl commands below the code to demonstrate its usage send requests to port 8000.
created time in 5 hours
issue commenthttp-rs/http-types
Suggestion: Use `oneshot::channel` instead of `async_std::channel`
Ah yes, though the benefits I mentioned of using a oneshot channel still apply.
comment created time in 5 hours
issue commenthttp-rs/tide
Bug Report | Connection timeout in Firefox for non-root paths
Thanks! Let me know if you find anything or are able to reproduce
comment created time in 7 hours
issue commenthttp-rs/http-types
Suggestion: Use `oneshot::channel` instead of `async_std::channel`
http-types currently only has an optional dependency on async-std for the file system stuff. for channels, it uses async-channel on main currently: https://github.com/http-rs/http-types/blob/main/Cargo.toml#L32
comment created time in 7 hours
issue openedhttp-rs/http-types
Suggestion: Use `oneshot::channel` instead of `async_std::channel`
There are a couple of places where a one-time channel is needed:
- Upgrading a connection
- Sending/receiving trailers
Currently these wrap the channel from async_std, but it would simplify things if they wrapped oneshot::channel
from futures (or other similar channel) instead, as that channel offers the following benefits:
- Simpler implementation and less synchronization, since only two tasks are involved.
- Send function does not need to be async.
Since this is a breaking change to the signature of send
, it should be done for the next major release.
created time in 9 hours
issue commenthttp-rs/tide
Bug Report | Connection timeout in Firefox for non-root paths
I will try to reproduce from the snippet, and see if I found some hints. Thx!
comment created time in 9 hours
issue commenthttp-rs/tide
Bug Report | Connection timeout in Firefox for non-root paths
I wonder if this has to do with the fact that async-h1 doesn't properly parse the keep-alive header
comment created time in 9 hours
issue openedhttp-rs/tide
Bug Report | Connection timeout in Firefox for non-root paths
I'm building a project using Tide and in my project, the response is returned after several seconds. In Firefox, this causes a "connection timeout". Though, I feel this is a tide error because the issue does not occur when the route's path is /
, only when it it a non-root path.
To reproduce:
- Run:
use tide::Request;
#[async_std::main]
async fn main() -> tide::Result<()> {
app.at("/test").get(test);
app.listen("127.0.0.1:8070").await?;
Ok(())
}
async fn test(_req: tide::Request<()>) -> tide::Result {
async_std::task::sleep(std::time::Duration::from_secs(6)).await;
Ok("a".into())
}
- Visit http://localhost:8070/test in Firefox
- See error:
This issue does not occur when the path is the root (when it has no segments other than /
):
app.at("/").get(test);
created time in 13 hours
startednurdism/neko
started time in 15 hours
startedbwasti/mebm
started time in 15 hours
startedgvinciguerra/PGM-index
started time in 16 hours
startedanatol/vmtest
started time in 18 hours
issue commentasync-rs/async-std
TCP connections don't work on wine
I don't know about the threadpool idea though. It might catch ppl by surprise.
By default our async FS operations already run on a threadpool; this will change with io_uring
/ ringbahn
eventually but only as an enhancement if we detect the OS has support for it.
I'm curious though: is the worry that the performance may not be good enough? Would it be enough if we documented this clearly?
AFAIK Wine has a few env vars set that make it obvious.
Yay!
comment created time in 18 hours
startedFishrock123/beautify-benchmark
started time in a day
startedlni/dragonboat
started time in a day
issue commentasync-rs/async-std
TCP connections don't work on wine
AFAIK Wine has a few env vars set that make it obvious. I don't know about the threadpool idea though. It might catch ppl by surprise.
comment created time in a day
pull request commenthttp-rs/tide
Add simple reverse proxy example
Good one
comment created time in a day
startedArchiveBox/ArchiveBox
started time in a day
issue commenthttp-rs/tide
Out of curiosity to understand this use case, do you have other routes in addition to these? If not, using tide will be slower than using async-h1 directly as a reverse proxy
comment created time in a day
issue commenthttp-rs/tide
I'm also trying to create a simple tide+surf based reverse-proxy.
I experienced the same behaviour and while hoping for the same expected behaviour...
The work-around I used was:
app.at("/").all(move |mut client_request: Request<()>| async move { ... });
app.at("*").all(move |mut client_request: Request<()>| async move { ... });
That combination should route all your unknown paths.
comment created time in a day
startedRustCrypto/hashes
started time in a day
startedatlassian/gostatsd
started time in a day
pull request commenthttp-rs/tide
Hi @jbr, If you have time can we make a quick talk to understand the design and how to resolve the regenerate
issue. Maybe is better to have an struct Session that holds an inner struct with a Arc<RwLock> but i'm not sure.
Thanks in advance!
comment created time in 2 days
startedCanCanCommunity/cancancan
started time in 2 days
issue commentasync-rs/async-std
TCP connections don't work on wine
smol
relies on wepoll
to work, and the wepoll
maintainer has replied here stating that this is in fact due to missing emulation in Wine. Fixing this would be non-trivial.
One option we could perhaps employ though would be to fall back to a thread-pool based implementation on Wine (based on blocking
+ std::net::TcpStream
). It'd be slow, but at least it wouldn't panic. Which I'm guessing would be a step up from the current status quo.
The question is how to detect we're running under Wine though. Perhaps we could scan whether the syscall exists and then swap backends? Perhaps Wine has a canonical way to allow people to detect it? We should probably figure that out since we shouldn't default to using the thread pool for all Windows targets.
comment created time in 2 days
push eventasync-rs/async-std
commit sha e11a7ecf3626c4c7bc4efda08e325e95ea4bd788
Fix typo in DoubleEndedStream docs
commit sha a4fb1733528068b454fc8c12751580b5f543feee
Merge pull request #944 from jackinloadup/patch-1 Fix typo in DoubleEndedStream docs
push time in 2 days
PR merged async-rs/async-std
Fix typo in current docs for DoubleEndedStream.
pr closed time in 2 days
issue commenthttp-rs/surf
Simple POST requests are getting split into 2 frames
Heya, thanks for reporting! -- to verify: which backend are you using? If it's curl then there's not much we can do since we entirely rely on their implementation; but if it's async-h1
we can probably dig into this deeper and ensure this doesn't happen.
comment created time in 2 days
startedgraphile/worker
started time in 2 days