Logged In: YES 
user_id=24670

> The address space available to each thread typically 
doesn't
> depend on the number of threads. Instead, the stack size 
is
> pre-determined, so it's vice versa: the number of threads
> supported depends on that stack-size, which (currently)
isn't tunable.

Yes, but my point is that on low-end and/or embedded system 
the system can be configured with as low stack per thread 
as possible (since with for example 100 threads, every 
extra 10K of stack per thread means 1M of extra memory, 
which in the absence of paging needs to be wired down) and 
if only one thread needs this stack 990K of it will be 
effectively wasted. And since getaddrinfo()-family already 
uses heap for its results I don't see any big win in 
avoiding extra malloc()/free() call. Expecially considering 
that we are dealing with i/o here, so that system call 
overhead will be much more than that anyway, even if the 
program calls those functions heavily.

-Maxim