[PATCH] close_connection_after_writing only if not deferred, as in cool.io
normalperson at yhbt.net
Sat Dec 29 13:26:01 UTC 2012
"Lin Jen-Shin (godfat)" <godfat at godfat.org> wrote:
> On Fri, Dec 28, 2012 at 4:43 PM, Eric Wong <normalperson at yhbt.net> wrote:
> > I definitely don't want to rely on GNU-isms in shell scripts,
> > it should rely on POSIX behavior.
> > It /should/ work on *BSD, I'll try again on FreeBSD tomorrow.
> I got managed to get them all passed now :D
> The problem is at `wc`. On my mac, wc would print
> some leading spaces even if you use `wc -c < random_blob`.
> $ echo 's' | wc -c
> After using coreutils from GNU or use sed to strip the spaces,
> everything passed, except for the one for Apache ab. I've heard
Ah, probably good to add a byte_count() function to test-lib.sh
to get around this... FreeBSD 9.0 does this, too.
I didn't manage to work more on FreeBSD, got distracted by bugs
in other projects...
> Also, after confirming all tests are fine, the only test which cannot
> pass for eventmachine with threads is:
> "send big pipelined identity requests"
> As you mentioned before, the issue is that there is no easy way to
> disable a connection and enable it later on? I tried `pause' and
> `resume', but it doesn't seem to work correctly? Or I might have
> done something wrong or missed something.
I think that was another issue I had with the EM thread
implementation I tried...
> If I took out this line to make Rainbows! buffer everything, it would
> also work.
> @_io.shutdown(Socket::SHUT_RD) if @buf.size > 0x1c000
> But I guess we shouldn't really buffer them in Ruby. I am still trying
> to solve this :/ You can find my working copy here:
> I don't paste it inline here because it's large and I guess we should
> make all tests pass. Or we could skip that test for this model?
Tests for features are fine to skip, but being open to such a
trivial DoS is not fine... Perhaps disable keepalive support
entirely? (you'd have to disable a lot of tests, perhaps
like StreamResponseEpoll :x)
> Another concern is that, the most straightforward implementation
> would be subclass Rainbows::EventMachine::Client to make it
> app_call in a thread. But there's em_client_class option which
> users might provide their own eventmachine connection.
That was for Cramp, I can't remember exactly how it worked...
> If I did this in a client class, then users who provide their own
> client class won't really respect the threads, making using
> EventMachine or EventMachineThreadSpawn basically the same.
> I think this is somehow unexpected.
They'd have to pick the threaded concurrency model. Maybe
more Ruby code is thread-safe nowadays...
> But then I realized using another option for threads or not really
> complicates the original implementation, this is not what I really
> want either. I am not sure if there's a perfect solution for this,
> so I just concentrate on passing all tests first...
Yes, Rainbows! already has so many options it's hard to keep
things straight :x
I believe EM is one of the concurrency options people actually use in
Rainbows!, so it's important to not break it. I don't mind copy+pasting
first and eventually factoring out the common parts if possible.
More information about the rainbows-talk