Timmy Brolin <[email protected]> wrote: > I had a look at the new lwip 1.4. It looks like > LWIP_TCPIP_CORE_LOCKING_INPUT is conditional on LWIP_TCPIP_CORE_LOCKING. > But that is not really necessary, is it? > I think it should be possible to enable only > LWIP_TCPIP_CORE_LOCKING_INPUT, without enabling CORE_LOCKING for the > netconn and socket APIs.
Well, that depends: there should be no problem with the socket/netconn API to use message passing (as if CORE_LOCKING==0), but the main loop of tcpip_thread (as well as the timer-processing mbox_wait function) will have to "lock the core" or it might be active in the stack at the same time as the input function. To achieve that, CORE_LOCKING must be splitted into "core locking available" and "use core locking from netconn API". > [..] If _INPUT > and _UDP can be made stable without too much effort, then people could > start using those, and continue using the traditional mailbox system for > TCP until core locking for TCP becomes a bit more stable. Well, the problem of separating CORE_LOCKING between TCP and UDP might be that the current code does not know (or care) at those places if a netconn is UDP, TCP or RAW. This would introduce additional 'ifs', I guess (which might again hurt performance). Simon -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
