Re: [lwip-users] CORE_LOCKING

[Kieran Mansley]

On Thu, 2011-07-14 at 20:41 +0200, Timmy Brolin wrote:
> Kieran Mansley skrev 2011-07-14 15:49:
> > On Thu, 2011-07-14 at 06:26 -0700, timmy brolin wrote:
> >> Yes, people most certainly use more than one of those APIs in the same
> >> project.
> >> tcpip_input is used by everyone, obviously.
> >> It also makes sense to use both netconn and netifapi in the same
> >> project.
> > I really meant does anyone use more than one of the raw API, netconn
> > API, and sockets API in the same project?  
> Yes,
> Since we are using a RTOS, we need support for multiple tasks. So we use
> netconn for complex protocols, and raw for simpler or high performance
> protocols.
> Not using sockets right now, but will probably use them for ported 3rd
> party software in the future.

OK, that (and Simon's similar reply) is useful to know.

> Question: When CORE_LOCKING is enabled, is there any reason why the raw
> API cannot be used in a multithreaded system as well? (Just lock lwIP
> before calling a raw API function, and unlock it right after)
> If that is the case, then netconn might not even be needed anymore...
> 
> Question2: What do you think about the state of CORE_LOCKING in
> tcpip_input and netconn? Are there any apparent problems, or are they
> good enough for production systems?

I have to be honest and say that I don't know, and I don't currently
have the time to investigate to give you the right answers to those.

> As far as I can tell, there would not be any actual code changes in lwIP
> to support individual configuration of CORE_LOCKING.
> All that is needed is:
> Replace "LWIP_TCPIP_CORE_LOCKING" with "LWIP_TCPIP_CORE_LOCKING_NETCONN"
> in all netconn files.
> Replace "LWIP_TCPIP_CORE_LOCKING" with "LWIP_TCPIP_CORE_LOCKING_SOCKET"
> in all socket files.
> Replace "LWIP_TCPIP_CORE_LOCKING" with
> "LWIP_TCPIP_CORE_LOCKING_NETIFAPI" in all netif files.

I would be (pleasantly) surprised if that was all that was needed.
Wouldn't there be problems if for example the netconn API was configured
to use core locking, but another task was using the raw API and it had
not been configured to use core locking?

Kieran