[lwip-users] another reentrancy question

[shogun]

<SNIP>

 "shogun" <address@hidden> wrote

> If you are running lwip without an OS, I am not clear on how this can be
> prevented if it is a problem.  If the main application can send data via a
> socket

That cannot happen: our sockets need an OS, so you won't have sockets
running without an OS.

> any time and the remote system on the other side can send data any
> time, if one side is sending and the other side also sends some data can
> this cause a reentrancy issue?  The send from the system running lwip is
> from the main loop but when the lwip system receives data isn't that
context
> of receive in an interrupt handler?

Well spotted. Therefore, your driver must not call lwIP's input functions
but put the RX packet on a list which is polled from the main loop.

>  In other words, do I have to be
> concerned about sending data from the lwip system and having the remote
> system also send data?

No. The Bly thing you have to be concerned about is whether your drive is
implemented correctly.

Simon

Simon,
I am running  LWIP on a Stellaris CPU without an OS.  I added a second
socket so now I have two sockets on two different ports and started seeing
some problems when I use both sockets.  One socket sends and receives data
for the application and the other socket is more of a debug port used to
output the "printf" data and receive debug commands etc.  I started seeing a
problem when I started using both sockets at the same time but the problem
is not consistent. When I am sending and receiving data on the main socket,
sometimes when I connect the second socket everything works fine and other
times I see the application appear to hang but when it's "hung" I stop it
with the debugger and see where it is executing.  Every time I stop it and
it is not working properly, it is in the file tcp_in.c, the function
tcp_input() and going between the two source lines below only:

(line 180) for(pcb = tcp_active_pcbs; pcb != NULL; pcb = pcb->next) { 


(line 201) prev = pcb;


I am running version 1.3.1.


I don't know if I am doing something wrong, or if it would help to use lwip
version 1.3.2 etc.

I do clear the memory in the receive function after I copy the data out to a
receive buffer like in this function:

static err_t main_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t
err )
{
        char *rq;
        static char debugStr[265];

        //UARTprintf("\nreceived...\n");
        if(p != NULL)
        { 
                rq = p->payload;
                EventHandler( rq );     // command parser / handler
                sprintf(debugStr, ">%s<\n", rq);
                tcp_recved(pcb, p->tot_len);//need to tell stack data
received                
                pbuf_free(p); // pbuf_free does not return an error code, it
returns the number of pbuf structures that were deallocated.
        }
        else //pointer is null
        {
                mainNetInfoStruct.portConnected = FALSE;
                //pbuf_free(p);
                main_client_close(mainNetInfoStruct.pcb);       
                UARTprintf("\nmain port disconnected...\n");
        }
        return ERR_OK;
}//end static err_t main_recv(void *arg, struct tcp_pcb *pcb, struct pbuf
*p, err_t err )

Both sockets seem to work one at a time fine and sometimes they work when
both sockets are sending and receiving data at the same time so this seems
like a timing issue, a race issue or a reentrancy issue. I don't know if
this is a problem with the pbuffs being shared internally between the
sockets or what the problem is.

About your comment " Well spotted. Therefore, your driver must not call
lwIP's input functions but put the RX packet on a list which is polled from
the main loop." This is still a bit confusing to me.  I create the sockets
in the main loop but they must run out of the interrupt handler since they
are only set up to listen in the main context.  When the main socket
receives data, I assume it is received and handled in an interrupt context.
The software may send some data back based on the data received and that I
am assuming would this would be sent from the same context the data was
received from.  Also, the main loop could get some data and send it so this
would probably be the exception to sending/receiving data for a different
context between mail loop/interrupt context.  I do not know if that is a
problem or not or if I am describing this right. 

Thanks again for your help,
DB