Use of pool servers reveals unacceptable crash rate in async DNS

Kurt Roeckx 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.


Kurt



More information about the devel mailing list