On Sun, Jul 20, 2014 at 4:33 PM, Alan M. Carroll <
a...@network-geographics.com> wrote:
> Theo,
>
> Sunday, July 20, 2014, 11:19:11 AM, you wrote:
>
> > Any reason to not simply use ck_hs and ck_ht from concurrency kit? That
> was
> > one of the points of looking at that library.
> > On Jul 19, 20
Theo,
Sunday, July 20, 2014, 11:19:11 AM, you wrote:
> Any reason to not simply use ck_hs and ck_ht from concurrency kit? That was
> one of the points of looking at that library.
> On Jul 19, 2014 11:33 PM, "Alan M. Carroll"
> wrote:
Only administrative reasons, in that as far as I know CK is n
Any reason to not simply use ck_hs and ck_ht from concurrency kit? That was
one of the points of looking at that library.
On Jul 19, 2014 11:33 PM, "Alan M. Carroll"
wrote:
> As part of my work on TS-2863 (FQDN support for server session sharing) I
> implemented a new variety of hash table. I did
On Jul 19, 2014, at 9:33 PM, Alan M. Carroll
wrote:
> As part of my work on TS-2863 (FQDN support for server session sharing) I
> implemented a new variety of hash table. I did this because none of the
> current hash table implementations were adequate. I hope this one is useful
> enough to
As part of my work on TS-2863 (FQDN support for server session sharing) I
implemented a new variety of hash table. I did this because none of the current
hash table implementations were adequate. I hope this one is useful enough to
be adopted as the standard.
The key point of this implementatio
