Hi Tomas,

> Is there any specific reason for this? Would you be OK with having
> a configuration option(s) in the 'lwres' statement that would
> enable setting the NTASKS/NRECVS to a different value?

No, there's no particular reason for that.  The lightweight resolver
never got much widespread adoption, so it's been neglected.  (Nobody
uses it -> nobody complains about it -> we don't fix broken things.
You know how it goes.)

We've actually considered deprecating it, and may yet do so,
but in the meantime I'd be happy to accept your patch.  There's a
system test in bin/tests/system/lwresd that might be an appropriate
place for any regression tests you wish to add.  Documentation
goes in chapter 5 of the ARM: doc/arm/Bv9ARM-book.xml.  

> Do you have any specific requirements on how such options should
> be named?

I would suggest they include "lwres", to clarify that these options
only affect lightweight resolver tasks.  I might use "lwres-tasks"
and "lwres-clients", for instance, with "lwres-tasks" defaulting to
ns_g_cpus (the number of CPUs, potentially overridden by the '-n'
option).  Clients would then be evenly divided amongst the tasks.
Up to you, though.

> Should there be any (maximum) limit for the values?

Well, at some point you'd hit system resource limits.  Offhand, I'd
suggest putting the maximum at 32768 clients, and default to 1024.
Perhaps consider using a lower default when running as named and a
higher one when running as lwresd.

The way clients work in lwresd is, unfortunately, broken and stupid.
In named, when it's necessary to recurse to answer a client query, the
ns_client object that handled the incoming query will replace itself
so that if more queries come in while it's recursing, there will be
another ns_client object there to handle them.  The lwd_client
objects used for the lightweight resolver don't do this.  If you get
them all busy doing recursion, all incoming queries are starved.
If we don't end up deprecating LWD, then one of these days we really
ought to combine its client-management code with ns_client.

--
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.