Leonard Hecker

Timeouts (issue #22) will surely help in making sure that clients do not use something like the Slowloris attack, but does this really solve _this_ issue? Because this issue needs...

Yeah this "fast-reject policy" is what I would have done too. But since @jedisct1 brought up this issue I've noticed how flawed this is... Because if an attacker manages to...

Yeah of course! (IMHO we should even take coroutines out of coio, since those are also useful without the I/O... What's the difference between this and coroutine-rs? Why not merge...

Hey @jedisct1! Just a heads up: We developed a "coroutine" barrier that works similiar to the well known thread barriers. We are (more than likely) going to use those to...

Ah good idea! I didn't think of this... Maybe we should add a method to the Scheduler that works just like Scheduler::ready(coro) but yields to the coro if it's on...

I've read it too now... So we either have to use the same thing as std (ACKs), or we have to wait until the queue is empty before we trigger...

We might want to thread::park()/unpark() the current thread and add it's handle to a processor wait list on the Scheduler... This thread would get unparked whenever Scheduler::ready() is called with...

I used to have this issue and it doesn't occur in the internal 1.16.2352.0 preview build anymore. Closing, because it'll be (hopefully - if I'm right) fixed in the upcoming...

> Why is this difficult to review? The code isn't _that_ trivial tbh. I honestly thought it was pretty solid when I opened the PR, but as you can see,...

@DHowett No I haven't worked on this yet. I was planning to continue with this PR once we forked off 1.16.