Simon Goldschmidt wrote: > 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". > Yes, like this: (In tcpip.h)
#if LWIP_TCPIP_CORE_LOCKING || LWIP_TCPIP_CORE_LOCKING_INPUT extern sys_mutex_t lock_tcpip_core; #define LOCK_TCPIP_CORE() sys_mutex_lock(&lock_tcpip_core) #define UNLOCK_TCPIP_CORE() sys_mutex_unlock(&lock_tcpip_core) #else #define LOCK_TCPIP_CORE() #define UNLOCK_TCPIP_CORE() #endif >> [..] 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 > True... Might not be worth it. But lwip_sendto should be possible? Regards, Timmy Brolin _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
