> On Wed, 15 Nov 2000, John Casu wrote:
>
> CC'ing this to the curl mailing list for information.
>
> > i) Is it possible to set the connections to be non-blocking, so that I
> > can increase the rate at which I am sending request packets, and reading
> > requests ?
> >
> > When I compare the results for ab to my benchmark for http (non ssl)
> > requests, I get considerably higher transaction rates (%20 faster) for ab
> > than for mine.
> >
> > I guess I *should* do this myself, but I figured it might be a
> > generally useful feature.
>
> I've planned to add non-blocking connections. I even have a mail in my inbox
> with an example how non-blocking connections are made in windows, which would
> also introduce better connect timeouts on that platform.
>
> It is only that same old problem: I'm loaded with work and ideas and I would
> need help to speed up things.
>
> I'd welcome a patch that introduces this, any time. I just don't know when
> I'll be able to write it myself.
>

ok... I'll see what I can do, at least for Linux.
I just wanted to check you didn't have something already in mind.

> > ii) curl_easy_setopt(handle, CURLOPT_STDERR, null_file), where null_file
> > points to /dev/null doesn't work. I have to freopen("/dev/null", "a+",
> > stderr) to get the desired effect.
>
> ... hm, and this is because:
>
> > after each curl_easy_perform(), a crlf is sent to stderr, and this is
> > kind of annoying. CURLOPT_MUTE doesn't fix this either.
>
> Right?
>
> It is an obvious error, I just committed a fix to lib/progress.c that removes
> that extra newline.
>
> Thanks for your feedback!
>
> --
> Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
> ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
>
>
>
Received on 2000-11-16