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: Lou Cypher
Subject: Re: [lwip-users] tcp_poll(), event handlers and possible misinformation
Date: Wed, 01 Jul 2009 15:17:16 +0200
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)

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

Well, interrupt won't come from tcp_fasttmr(), but from the caller.
It's quite usual having hardware timers, with an automatic reload, that
interrupt processing at a predefined rate: from there I can call tcp_fasttmr(),
tcp_slowtmr() and all the the other timing functions.

Yes, there are issues to keep in mind, like the requirement for secondary
functions (called from handler), like tcp_fasttmr(); they shall execute "fast
enough" to avoid missing next timer tick.
If lwIP processing were slower than 250 ms (TCP_FAST_INTERVAL), well... I should
better change my processor...
Once avoided all the downsides you can have the benefit of a well defined
tick/interrupt rate (beside interrupt response).

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

And so I will do, to avoid contention.
My drawback is that having a co-operative scheduler I can't guarantee a constant
timer call: from some call to the next I could have some jitter.
I presume that having 250 ms on a cycle, and 255 on the next, won't kill lwIP, 
true?

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

That confirms what I've experienced.
Now I'm just trying to understand what to do when poll calls for input: I just
analyzed a PCB passed to my poll(), nothing to transmit, no pcb->refused_data to
process, and the call to poll() has no pbuf*
How do I manage the received data? (and how do I reach it?)

Lou

____________________________________________________________
Receive Notifications of Incoming Messages
Easily monitor multiple email accounts & access them with a click.
Visit http://www.inbox.com/notifier and check it out!




reply via email to

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