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

["Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org>]

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
that ab is broken on mac, and after install ab from:
https://github.com/Homebrew/homebrew-dupes/pull/102
Tests using ab are all passed too.
ref: http://simon.heimlicher.com/articles/2012/07/08/fix-apache-bench-ab-on-os-x-lion

Nothing to do with grep.

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.

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?

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.

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.

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...
_______________________________________________
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