I talked to Simon about this at work, because I also have my problems in understanding that code.
What became clear to me is: The main problem is on how you see these events. You and I mostly think of them as mapping accept, receive, send to events, but they are not designed like this.
A better approach to understand them is:
You have three ways to block a client:
- accept mbox (sys_arch_mbox_fetch(&conn->acceptmbox, &accept_ptr, 0);)
- receive mbox (sys_arch_mbox_fetch(&conn->recvmbox, &buf, 0);)
- send queue is full (sys_arch_sem_wait(LWIP_API_MSG_SEM(msg), 0);)
The events have to be seen as events signaling the state of these mboxes/semaphores. For non-blocking connections, you need to know in advance whether a call to a netconn function would block or not, and these events tell you about that.
PLUS events say: Safe to call once. They are counted in sockets - three RCVPLUS events for accept mbox means you are safe to call netconn_accept 3 times without being blocked. Same thing for receive mbox.
MINUS events say: You call to to a possibly blocking function is "acknowledged", sockets decrement the counter.
For TX, there is no need to count, its merely a flag. PLUS means you may send something. A MINUS event occurs when the next call to a netconn_send() would be blocking. PLUS occurs when enough data was delivered to peer so netconn_send can be called again.
I hope this sheds some light on this. This really needs to be documented :-) - if you like, send me a text, I'll commit it.
My explanation is still not perfect, I'm trying to write down what Simon told me at work, but I did not reanalyze the netconn code to see if everything is correct.