lwip-users
[Top][All Lists]
Advanced

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

[lwip-users] lwIP reentrancy issues and TCP


From: Peter Montgomery
Subject: [lwip-users] lwIP reentrancy issues and TCP
Date: Fri, 24 Jun 2011 10:42:13 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11

I'm working on a basic TCP client using lwIP 1.32 on a TI LM3S6965 chip without an RTOS. Much is made of the fact that lwIP is non-reentrant, so you're supposed to have everything happen in the interrupt handler. OK, but how is a client that needs to transmit independently supposed to work?

My TCP client often needs to send messages without receiving one. This means there isn't an incoming message to trigger an outgoing message. Outgoing messages can occur at any time when the client needs to send one. What is considered the correct code architecture for a TCP client that needs to transmit independently of received messages?

It's no big deal to have the incoming TCP handled by the interrupt handler. I have even gone ahead and created a ring buffer that incoming messages are placed in. This lets the foreground code (non-interrupt code) pull messages from a shared buffer and deal with them. I want the foreground code to have time to handle messages and not bog down the interrupt response time.

However, do I really have to do this for transmitting messages as well? Do I have to create a ring buffer, place outgoing messages in it, and have the systick timer used by lwIP check if there are new messages to send? This seems really inefficient for throughput.

I was told on a different message thread that calling "tcp_write" from the foreground was a bad idea since it meant two threads (foreground and interrupt) were potentially in the TCP/IP stack at the same time. However, I have seen many (most? all?) examples of TCP code samples using this exact approach. This doesn't mean it's correct, but it is sure is confusing to keep seeing sample code like this. I have tried calling "tcp_write" from the foreground and it appears to work fine. However, I don't want to have it blow up later.

Is lwIP really engineered so that the most logical situation (incoming TCP handled in the interrupt handler, "tcp_write" called from the foreground) is not allowed? Even with "SYS_LIGHTWEIGHT_PROT " set to 1 ? Shouldn't the lightweight protection be the kind of thing that handles this? If not, what are the situations that "SYS_LIGHTWEIGHT_PROT" handles?

Thanks,
PeterM



reply via email to

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