[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Reason for sndbuf checking in netconn_write
From: |
clive |
Subject: |
[lwip-users] Reason for sndbuf checking in netconn_write |
Date: |
Thu, 22 Mar 2007 13:48:51 +0000 |
User-agent: |
Demon-WebMail/2.0 |
Dear All,
I'm struggling to understand the reasons behind why netconn_write is written in
the way it has been, and hope someone can provide a brief explanation.
Specifically, I'm looking why there would be a need to pend on the semaphore
waiting for sndbuf to have some free space, i.e.:
if (tcp_sndbuf(conn->pcb.tcp) == 0) {
sys_sem_wait(conn->sem);
if (conn->err != ERR_OK) {
goto ret;
}
}
The reason I ask is that later in the call, the API_MSG_WRITE message is posted
to the tcpip thread, and (this is the important bit) the current thread context
will block in the next line (sys_mbox_fetch), waiting for the tcpip thread to
finish its API_MSG_WRITE message processing.
Surely this means that once the sys_mbox_fetch has returned, the space taken up
in the sndbuf for this write has been cleared? So due to this, sndbuf
management is handled implicitly. So why the need to have a sys_sem_wait
earlier in the while loop? It doesn't seem necessary to me...
Have I misunderstood something somewhere?
Very many thanks in anticipation,
Clive Wilson
- [lwip-users] Reason for sndbuf checking in netconn_write,
clive <=