1) have loopback communication running
2) produce very high load (i.e. flooding)
from the outside
results in:
- The ethernet driver running in interrupt
context sends a new TCPIP_MSG_INPKT to the mbox which is then full.
- The loopback also wants to output
a packet and calls tcpip_callback() which blocks on sending it's message
to the mbox.
This creates a deadlock since the tcpip_thread
is waiting for the mbox to be free again but it won't since that same thread
is responsible for fetching from the mbox.
I can fix the behavior by having MEMP_NUM_TCPIP_MSG_INPKT
be smaller than TCPIP_MBOX_SIZE. Then tcpip_input() fails before being
able to fill up the mbox.
Still it does feel like a design flaw.
Did I do something wrong? Should we
include this in the sanity checks on compile? Should the behavior be redesigned?