On Wed, Jul 1, 2009 at 9:17 AM, Lou Cypher<[email protected]> wrote: >> 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?
That jitter won't kill lwIP. Re-entering it will though. It's your responsibility to make sure you don't re-enter lwIP. I don't see any reason why you couldn't implement a model where lwIP can be entered from any of: 1. timer interrupt 2. NIC interrupt 3. <non-interrupt event> However, in all cases, you must make sure you don't enter lwIP while you're already in it. >> 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?) Not sure I follow this: Poll doesn't "call for input". The poll mechanism is for your convenience. You don't have to use it. If you have no data to process, don't request a poll. If your recv handler gets data that it cannot process right now for some reason, you could simply keep a pointer to the pbuf in your own data structure, rather than "refusing" it. Then you could request a poll and the pbuf would be available to you in your poll handler. Jeff _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
