lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] CORE_LOCKING


From: Kieran Mansley
Subject: Re: [lwip-users] CORE_LOCKING
Date: Thu, 14 Jul 2011 14:49:14 +0100

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?  

> 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?

Kieran




reply via email to

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