I was investigating on how it comes that tcp_poll() handler is called even on receive packets -- I thought it was *only* for transmit ones, while with httpd and large POST messages, I see it called on packets delayed/missed in handling
Left aside the first problem (...) I noted how event handlers are called in tcp_fasttmr() and tcp_slowtmr(), and I started figuring something wrong that can happen. Surely I'm not well into lwIP internals, but I'd like someone to clarify my hypothesis: - Suppose you are handling a packet of data, in the handler set with tcp_recv(). - While doing your chores, a new packet is/becomes ready/late, and the timer you connected to tcp_fasttmr() and/or tcp_slowtmr() fires an interrupt. - The interrupt stops your handler in the middle, and the timer function finds some PCBs that need processing, calling again the tcp_recv() handler: isn't this kind of reentrancy fatal? It's true that even in that case the library could depute any semaphore handling to the handlers, but I don't remember I found such a note anywhere, nor the httpd server in contrib does expose it. Even if the conjecture holds true, I wouldn't file it as a bug, but just as "missing information" about usage. About the original problem: if I get called for tcp_poll, and there's nothing to send, should I call my recv handler? (...) Lou ____________________________________________________________ GET FREE 5GB EMAIL - Check out spam free email with many cool features! Visit http://www.inbox.com/email to find out more! _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
