cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCHES RFC 2/2] Optional hash table improvements

From: Robert Iakobashvili <>
Date: Wed, 2 May 2007 18:05:34 +0200

On 5/2/07, Daniel Stenberg <> wrote:
> On Tue, 1 May 2007, Robert Iakobashvili wrote:

> hash_fd() is added as a library-wide symbol. If it should remain so, it should
> be Curl_ prefixed, but it seems to only be used from within multi.c so I
> suggested it is moved there and made static. What do you say?
> fd_key_compare seems to be in the same position.

I am used to keeping hash functions in some visible place, so that other
modules could use it when necessary, but no problems with keeping them

> > return ((fd < (int)slots_num) ? fd : fd % (int)slots_num);
> Is this complication really necessary? I mean, why not just do it:
> return fd % (int)slots_num;
No problems with both impementations

> > 2) curl-socket-hash-table-size.patch - is a very optional patch
> > improving the performance only above 10K curl handles;
> I figure upping that size is okay. Possibly we should consider a way to either
> let the app somehow set it or perhaps allow it to grow somehow. Of course we
> can even consider a different hash implementation that can deal with 10 or
> 10000 entries in a way that doesn't require us to change a fixed array size
> like this.

When it is an ifndef-ed define, one may overwrite it.

> I mean, if someone goes mad and tries 100,000 connections they probably will
> see that upping this size even more will be very beneficial to them...

Actually, we were really planning doing that in a couple of months...
and our madness is limited only by some more urgent features/issues and absence
of appropriate HW.


Robert Iakobashvili,
coroberti %x40 gmail %x2e com
A web testing and traffic generation tool.
Received on 2007-05-02