curb ruby 1.9.1

[taf2]

Hi All,

I have some good news. First, curb now compiles and runs with ruby
1.9.1. Second, I have permission to update the rubyforge project
merging in my feature changes. I think this also means it's a good
idea to migrate this list to the list managed over on rubyforge.
Before I land my changes back into the rubyforge project, if you all
can give the updated version on github a good testing and report back
on any further issues, that would be very helpful. I would like to
get the current issues with Post resolved before making the release.

-Todd

[Florian]

Hi Todd,
firstly, thanks for your answer regarding the array - it was indeed an
integer...

I am having trouble getting curb to compile with 1.9.1 seems like a
definition is missing: CURLMOPT_MAXCONNECTS

Error attached.
Thanks,
Florian


curb_multi.c:93: error: 'CURLMOPT_MAXCONNECTS' undeclared (first use
in this function)
curb_multi.c:93: error: (Each undeclared identifier is reported only
once
curb_multi.c:93: error: for each function it appears in.)

[Todd Fisher]

Okay,  I made a new release that detects if your version of libcurl supports CURLMOPT_MAXCONNECTS, if it doesn't using  multi.max_connects = ##  will not do anything.  The fix is in gem version 0.3.2

-Todd

[Florian]

Hey Todd,
thanks for your response. I am seeing some weird behavior though when
trying to establish outbound HTTPS connections when using curb with
1.9.1. The first connection succeeds and following that I am getting
502 errors, as if SSL connections weren't supported with multiple
threads. Any clues or weird behavior that you have seen here? It all
works fine with the old ruby though very slow :)

Thanks,
Florian

On Mar 21, 6:28 am, Todd Fisher <todd.fis...@gmail.com> wrote:
> Okay,  I made a new release that detects if your version of libcurl
> supports CURLMOPT_MAXCONNECTS, if it doesn't using  multi.max_connects = ##
>  will not do anything.  The fix is in gem version 0.3.2
> -Todd
>

[Todd Fisher]

The only issue, I know of when making SSL connections through libcurl is the possibility of openssl sending SIGPIPE when a client closes the connection early.

As for things being slow with ruby 1.8, do you have some example code that shows the slowness it shouldn't be *slow*

And in ruby 1.9.1 it sounds like that is a bug, do you have a sample to reproduce.

Thanks,

Todd

[Florian]

Hey Todd,
thanks for your speedy response. I think it might be an issue with a
curl library.
if a domain-name has an alias, and you connect to that alias, it's not
resolved, but CURL
does a "Host: ALIAS" not a "Host: REFERENCED_HOST"...
any way to get around that?

As for 1.8 ~ it's threading related ~ i.e. i have 20 concurrent
connections so imho, i should have quite a speedup with ruby 1.9 since
it supports real threads...

Thanks!

On Mar 24, 12:18 pm, Todd Fisher <todd.fis...@gmail.com> wrote:
> The only issue, I know of when making SSL connections through libcurl is
> the possibility of openssl sending SIGPIPE when a client closes the
> connection early.
> As for things being slow with ruby 1.8, do you have some example code that
> shows the slowness it shouldn't be *slow*
>
> And in ruby 1.9.1 it sounds like that is a bug, do you have a sample to
> reproduce.
>
> Thanks,
> Todd
>

[Todd Fisher]

On Tue, Mar 24, 2009 at 5:20 PM, Florian <flole...@gmail.com> wrote:

Hey Todd,

thanks for your speedy response. I think it might be an issue with a
curl library.
if a domain-name has an alias, and you connect to that alias, it's not
resolved, but CURL
does a "Host: ALIAS" not a "Host: REFERENCED_HOST"...
any way to get around that?

I'm not entirely sure how to help here with this are you sure the DNS configuration is setup correctly?  Might want to ask this question on the libcurl mailing list or in #curl on freenode. 

As for 1.8 ~ it's threading related ~ i.e. i have 20 concurrent
connections so imho, i should have quite a speedup with ruby 1.9 since
it supports real threads...

Actually, curb does most of the network connection processing in kernel space so 1.8 should be much more efficient in the case of 20 threads then ruby 1.9.   Most of the processing for each connection is happening in the kernel not your application.  In ruby 1.8, threads are *simulated* in that the interpreter would schedule execution of code by selecting between threads using the system call select.  The same code that decides which thread to run next also handles all IO in ruby 1.8.  This means when dealing with network IO with threads - ruby 1.8 is closer to a multiplexing IO pattern then in ruby 1.9 where it runs the code in a real posix thread.  The advantage of ruby 1.8's model for threading when doing lots of IO, is you can make multiple socket and disk IO operations using a single process with single thread.  In contrast, ruby 1.9 uses real posix threads so now you the programmer have to be smarter about how you write your socket and disk operations.   curb makes this easy, with the multi interface you can make multiple network requests within a single thread using ruby 1.9 or ruby 1.8....  Hope this clears things up.