Use of pool servers reveals unacceptable crash rate in async DNS
kurt at roeckx.be
Sat Jun 25 22:53:25 UTC 2016
On Sat, Jun 25, 2016 at 06:13:56PM -0400, Eric S. Raymond wrote:
> Hal Murray <hmurray at megapathdsl.net>:
> > esr at thyrsus.com said:
> > > 1. Apply Classic's workaround for the problem, which I don't remember the
> > > details of but involved some dodgy nonstandard linker hacks done through the
> > > build system. *However, I did not trust this method when I understood it.*
> > > It seemed sure to cause porting difficulties and is inherently fragile.
> > kurt at roeckx.be said:
> > > If it's the one I'm thinking about, I think the solution is to remove the
> > > locking of memory.
> > We may be confusing several bugs.
> > There was a problem with locking stuff into memory. Some library needed by
> > end of thread processing wasn't loaded yet and things worked out such that
> > with the default memory 32 bit systems worked but 64 bit systems didn't have
> > enough room.
> > I think one solution was to create a dummy thread early on to get that module
> > loaded. Or disable memory locking, or tell it to use more memory, or ...
> This matches what I remember, except for "use more memory". There was a third
> workaround involved weird linker options to force early loading of the library.
Like -WL,-z,now? That's not such a weird option.
More information about the devel