Re: [lwip-users] CORE_LOCKING

[Timmy Brolin]

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.

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?

>
>> Getting CORE_LOCKING working reliably on all interfaces, and get rid
>> of the message passing altogether, would be great. I can't agree more.
>> But there is lots of work to be done on CORE_LOCKING in the socket
>> interface, and there has been almost no progress at all made on
>> CORE_LOCKING for years..
>> I think that the consesus some time back was that it would be best to
>> write a completely new socket implementation with CORE_LOCKING, rather
>> than adapt the current socket implementation.
> That's correct.
>
>> I think that code which is not used, will not be improved/maintained
>> very well either.
> Also true.
>
>> By making the CORE_LOCKING option individually configurable on a API
>> basis, people can start using CORE_LOCKING on those APIs where it
>> already is in decent shape.
> They can already do that, as long as they're only using the APIs where
> it is already in decent shape, which although I agree isn't ideal it is
> "good enough" for some. 
>
> I'm worried that trying to support one API with core locking and another
> without core locking at the same time would be difficult and complicate
> the code considerably.  Wouldn't we be better spending that developer
> time on improving the core locking code, rather than providing yet more
> options?
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.

A preprocessor dependency check can be added for good measure.

/Timmy Brolin