[squid-dev] [RFC] Fix shared memory initialization, cleanup. Ensure its usability.

[Alex Rousskov]

On 12/09/2015 04:24 PM, Amos Jeffries wrote:
> On 10/12/2015 10:49 a.m., Alex Rousskov wrote:
>>>> Questions: Should we add a configuration directive to control whether
>>>> mlock(2) is called? If yes, should mlock(2) be called by default?
>>>> Should mlock(2) failures be fatal?

>>> My answers are no, yes, yes. Since this is a startup thing squid.conf
>>> post-processing is probably too late.


>> Shared memory is not allocated until _after_ we parse squid.conf.


> Ah. Okay.


Does this understanding change your no/yes/yes answers?

If your answers stay the same, what do you propose to tell admins that
will complain about significantly slower startup times after this fix?
My plan was to tell them to disable mlock() (via a new squid.conf
directive) if all of the items below apply to them:

(a) mlock() is successful now
(b) they are reasonably sure no environment or configuration changes
    will make mlock() unsuccessful (if it is re-enabled) without them
    knowing about the problem
(c) mlock() slows things down too much in their setup
(d) they want to trade faster startup for micro delays during runtime


Thank you,

Alex.