[Top][All Lists]

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

Re: [lwip-commits] [SCM] lwIP Contrib - Contributed code for Lightweight

From: Joel Cunningham
Subject: Re: [lwip-commits] [SCM] lwIP Contrib - Contributed code for Lightweight TCP/IP stack branch, master, updated. STABLE-2_0_0_RELEASE-191-g4c854d4
Date: Tue, 02 Jan 2018 12:58:23 -0600
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 1/2/2018 12:40 PM, address@hidden wrote:
Joel Cunningham wrote:
which showed the problems in
bug #52719 and also some other problems with tcpip_init() and executing
the initfunc (which currently does not have the core lock held).

We were already talking about the init phase earlier this day. The problem here is that with our systems, the init phase is executed before the OS is started (and all threads are of course created suspended until the scheduler is started). In this setup, you can't acquire the core lock (e.g. calling netif_add() after tcpip_init() from your main function).

Ok, that makes sense and you're using the execution of the tcpip_thread to know when the "OS" has started for the purpose implementing sys_check_core_locking?

My RTOS environment is setup differently where LwIP is only inited after the OS is up and running.  Maybe adding some kind of "init_done" state variable could be used instead of looking at the tcpip_thread to know this information?

If you're talking about the fact the the init callback is called from tcpip_thread without the lock held, go ahead and fix it - you're right ;-)

Yes this was the second issue I found after working around tcpip_init not having the core lock held during the call to lwip_init().  I agree this looks like a real bug and it didn't show up when running the win32 test port due to checking 'current_thread_id == lwip_tcpip_thread_id'.  I can push a fix


reply via email to

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