[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Resource starvation

From: address@hidden
Subject: Re: [lwip-users] Resource starvation
Date: Sun, 13 Feb 2011 19:38:10 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv: Gecko/20101207 Thunderbird/3.1.7

Yoav Nissim wrote:
I've opened a ticket for this issue on savannah, and have a few
problematic points left.
1. Could you give some feedback as to how we should process each of the
PCB queues? (e.g retiring a PCB but leaving it to be cleaned up later
vs. calling the upper layer with an error such as ERR_ABRT). We're not
sure what the correct behaviour should be for each of the PCB types/states.
I would have thought the code for this is already present in netif_set_ipaddr()? I just would have moved this code to a more generic function so that it aborts all PCBs which are using the netif's IP address as their local address (only if the address is changed, listening PCBs can silently be corrected, I guess). Aborting these PCBs leads to ERR_ABRT for the upper levels. PCBs using the ANY address can live on.
2. I believe this modification has exposed another problem: We get an
ASSERT when our PPP link is disconnected while packets are being
actively transferred.
The old PPP code was really broken regarding multithreading. The modifications that were necessary include that *none* of the PPP functions may be called from any other thread than the tcpip_thread (or the main loop for NO_SYS==1). The single exception here is pppInProc(), which can be called from another thread if PPP_INPROC_MULTITHREADED==1 (the reason for this is that it would otherwise be quite unperformant since we would call into tcpip_thread for every byte vs. every packet).

I'm sorry the change here hasn't been clear, but this is just how lwIP works, and the way it was before, it wasn't really thread-safe.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]