|
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:
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?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).
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
Joel
[Prev in Thread] | Current Thread | [Next in Thread] |