Re: [PATCH] close_connection_after_writing only if not deferred, as in cool.io

[Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>]

"Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 28, 2012 at 4:43 PM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> 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
>        2
> 
> 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:
> https://github.com/godfat/rainbows/pull/2/files
> 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.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying