[Top][All Lists]
[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!
- [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Kieran Mansley, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation,
Lou Cypher <=
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Jeff Barber, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, address@hidden, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, address@hidden, 2009/07/01
- Re: [lwip-users] tcp_poll(), event handlers and possible misinformation, Lou Cypher, 2009/07/02
- RE: [lwip-users] tcp_poll(), event handlers and possible misinformation, Bill Auerbach, 2009/07/01
RE: [lwip-users] tcp_poll(), event handlers and possible misinformation, Bill Auerbach, 2009/07/01