RE : [lwip-users] Reason for sndbuf checking in netconn_write

[Frédéric BERNON]

Give a look to https://savannah.nongnu.org/patch/?3796. Perhaps some 
idea/solution/explanation ? 
  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de address@hidden
Envoyé : jeudi 22 mars 2007 14:49
À : address@hidden
Objet : [lwip-users] Reason for sndbuf checking in netconn_write


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 mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-users

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf