[En-Nut-Discussion] killing threads waiting for a connection in NutTcpAccept

[José Vallet]

Hello Thiago.

Thiago A. Corrêa wrote:
> Hi,
> 
> On Tue, Apr 7, 2009 at 7:59 AM, José Vallet <jose.vallet at hut.fi> wrote:
>> The main reason is to save memory. Other than that is simply to not to
>> have a thread running that is not necessary, but as you might understand
>> this is not a powerful one.
>>
> 
>   You mentioned earlier that you have more than one thread, perhaps
> like the httpd example, where it launches several threads waiting for
> connection. You could reduce the number of IDLE threads (and perhaps a
> small bit of memory) by launching threads after the NutTcpAccept, so
> you have at most 1 IDLE thread, that you must have anyway to keep the
> service available.

Actually that is the case partially. We had 5 threads with httpd 
servers, one with a telnet server, another 2 with a control and 
monitoring processes and another for a serial terminal. At some point we 
were running out of memo and we had to reduce the number of http servers 
to 2, as the rest of the threads are either permanently or every now and 
then needed. That solved the problem, but our system is growing and will 
continue to, so I expect to have to face a similar situation again.

>   Other than that, you could try to do lazy memory allocations. This
> includes avoiding static memory allocations, since the compiler will
> reserve that chunk at compile time, even when not passing thru that
> portion of the code.

Yes, indeed that is one option that we have to exploit more (mental 
note!). But as I said our system is growing, and there might be 
situations where we don't have any other option than shutting down a 
server that is not being used, and start it only when it is necessary. 
So, coding for an optimal memory use will make us good, but sometimes 
not enough.

I guess that for now we will have to live with a dirty solution to 
unblock NutTcpAccept.

Regards,
José