[lwip-users] tcp_poll(), event handlers and possible misinformation

[Lou Cypher]

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!