>Of course it can.  If you have an app that needs more than 128, make it
>properly configurable so you can set the number properly.  

But Perry's arguing for this as a sensible default value, for most
apps, under most circumstances.  If you're now assuming the app can be
configured, then I think you're begging the question Perry is
attacking, which is dumb apps. (If you can tune the backlog of a
precompiled binary, who cares what the default is?)

What I'm proposing is a _different_ name for a sensible default value
that works for most apps under most circumstances. That way, normal
apps ask for the normal backlog, but potential pigs can ask for
whatever the maximum is.  If they ask for it, then they get it.

I'm not proposing it for normal everyday use.


>Defaulting SOMAXCONN to INT_MAX would result in the horrible impact that
>all apps using SOMAXCONN would get an immense backlog if one ever needed
>it.  That is not acceptable.

Uh, I'm suggesting you should only use SOMAXCONN for NetBSD apps if
you *want* an immense backlog. Otherwise, you ask for a reasonable
backlog.   I think that's Todd's perspective too.

For portable source code, you can do

#ifndef SODEFAULTCONN 
#   define SODEFAULTCONN SOMAXCONN
#endif

use SODEFAULTCONN in the code, and you're no worse off than your
way. But right now, SOMAXCONN isn't very useful as a default for
portable code _anyway_: it already spans 3 orders of magnitude (from 5
to 128 to 1000). So I dont see how NetBSD keeping the meaning of "max
possible backlog" affects portability in any signficant way.


That said, I spose one could code a known listen-pig app using INT_MAX
as backlog.  But that _would_ have the ghastly effects you describe,
on any system which don't have a sysctl equivalent for the upper
bound.

I think the bottom line is, this isn't worth wasting much more
bandwidth on:)