lwip-users
[Top][All Lists]
Advanced

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

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


From: Kieran Mansley
Subject: Re: [lwip-users] tcp_poll(), event handlers and possible misinformation
Date: Wed, 01 Jul 2009 13:28:11 +0100

On Wed, 2009-07-01 at 14:12 +0200, Lou Cypher wrote:
> 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.

I'm not sure why the timer handling functions would be raising
interrupts.

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

This shouldn't happen.  The "normal" way to avoid such things is to not
process packets in the interrupt handler, but instead to queue them for
processing by the stack.  This way there is only a single thread active
in the stack at any one time. 

> About the original problem: if I get called for tcp_poll, and there's nothing 
> to
> send, should I call my recv handler? (...)

>From the raw API documentation:

====
When a connection is idle (i.e., no data is either transmitted or
received), lwIP will repeatedly poll the application by calling a
specified callback function. This can be used either as a watchdog
timer for killing connections that have stayed idle for too long, or
as a method of waiting for memory to become available. For instance,
if a call to tcp_write() has failed because memory wasn't available,
the application may use the polling functionality to call tcp_write()
again when the connection has been idle for a while.

- void tcp_poll(struct tcp_pcb *pcb, u8_t interval,
                err_t (* poll)(void *arg, struct tcp_pcb *tpcb))

  Specifies the polling interval and the callback function that should
  be called to poll the application. The interval is specified in
  number of TCP coarse grained timer shots, which typically occurs
  twice a second. An interval of 10 means that the application would
  be polled every 5 seconds.
====

i.e. The tcp_poll callback is not specific to sending data, it's just a
method for the application to retry anything that it thinks might be
necessary.

Kieran





reply via email to

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