patelbaroda wrote:
I have one thread for web server, that call "netconn_write" function. The
other thread is from ethernetif.c that handles the MACB input packets. The
TCPIP thread is handling TCPIP process as defined
sys_thread_new(TCPIP_THREAD_NAME, tcpip_thread, NULL,
TCPIP_THREAD_STACKSIZE
I have one thread for web server, that call "netconn_write" function. The
other thread is from ethernetif.c that handles the MACB input packets. The
TCPIP thread is handling TCPIP process as defined
sys_thread_new(TCPIP_THREAD_NAME, tcpip_thread, NULL,
TCPIP_THREAD_STACKSIZE, TCPIP_THREAD_PRIO);
pragnesh patel wrote:
> There is only one connection. As I understand, the crash inside
> tcp_enqueue() may be because of two threads (one from incoming request through
> tcp_in.c) and other outgoing request) and needs protection. But as newcomer to
> lwip world, I don't know where to protect.
Ta
On Mon, 2009-12-07 at 09:02 -0800, pragnesh patel wrote:
>
> There is only one connection. As I understand, the crash inside
> tcp_enqueue() may be because of two threads (one from incoming request
> through tcp_in.c) and other outgoing request) and needs protection.
> But as newcomer to lwip worl
Marco Jakobs wrote:
> But i have to also get rid of the RAW stuff, because i want to do some
> changes concerning NAT support ...
And NAT support can't be used with the raw API? I'd be surprised about that...
Although I haven't used NAT for lwIP yet.
> And relating to this, my question to you (
Thank you, Simon ... the
conn->err query saved my day ;-)
I rewrote my connection status detection using the err variable and it
works perfectly!
RAW API is a pretty good thing, but the problem is that they are not
thread-safe ... so it's some complicated using them in a FreeRTOS
project wher
