Hello Simon
Thank you for your answer. For me there come a few more question up.
Quoting Simon Goldschmidt <[email protected]>:
Ueli Niederer <[email protected]> wrote:
- Am I missing something if I wrap every tcp_*-call and the
relevant portions of a callback in SYS_ARCH_PROTECT/SYS_ARCH_UNPROTECT
calls if I want to cross a context border?
In your scenario below (where the input and timer processing is
effectively locked, already, since it runs in the ISR context that
you protect from, I assume), it should suffice to lock interrupts
for all calls into the stack (i.e. tcp_write, etc.).
Your assumption is correct: The whole TCP/IP stack runs in the context
of the ISR which I have to protect against the main loop. In fact
SYS_ARCH_PROTECT is implemented by disabling the interrupt line to the
CPU core in TI's Stellaris "NO_SYS" port.
This assumes that the stellaris netif driver can handle this correctly.
Do you have any possible "incorrect handling" in mind while writing this?
- Is it correct, that pbuf_*-calls and memp_*-calls are already
constructed thread-safe?
Partly. Allocation/deallocation and pbuf_ref() are safe as long as
SYS_ARCH_PROTECT is implemented correctly and enabled, they should
be safe to use from ISR vs. application level. Other functions like
pbuf_header() are not safe, but in your scenario, that should be OK.
Ok, maybe for a easy capsulation it would then be better to protect
every use of lwIP functions instead of forgetting a function that
should have been protected, right? So for example it would be
nescessary to protect a chaining of received pbufs or a call to
tcp_close should also be protected, etc.
In general, it would be a better idea to enqueue RX packets for
processing at application level, though, so that lwIP runs
completely at application level.
I agree with that. Unfortunately my part is only a piece of a bigger
project which is already implemented on top of TI's port so I don't
want to take too much risk there by changing everything.
Thank you for your advice.
Ueli
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
