| delorie.com/archives/browse.cgi | search |
Dave Korn wrote: > Regardless of how well (or poorly) the > hash function distributes DLLS into the various buckets, there are only 1024 > of them, and we have many DLLs, many of which will occupy multiple buckets; > collisions are inevitable. First of all, I don't see where this 1024 comes from. By my reading the hash distributes over the range 0x61300000 - 0x712C0000 in 64k increments, meaning 4092 buckets. But what I really meant wasn't necessarily to improve the hashing function per se but to give it more buckets, a wider range. I realize that higher than 0x712c0000 tends to run into the Microsoft-assigned ranges for things in %systemroot%\system32, but it could also place things on the other side of the Cygwin DLL as well. Isn't that what Reini is trying to do here anyway? I guess my meta-point is that if we have a problem with the way we distribute image bases, shouldn't we try to find a way to solve that problem once in a central manner at the time the DLL is created by the package maintainer, rather than making the end user deal with it by brute force of resuffling everything on their system (in a way that is non-obvious if they are not familiar with the problem.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |