lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : [lwip-devel] Comments about "low_level_output"


From: Frédéric BERNON
Subject: RE : [lwip-devel] Comments about "low_level_output"
Date: Wed, 30 May 2007 16:05:07 +0200

>That seemed strange to me when I first looked over the code. More, if I call 
>netconn_addr() after a send that went wrong, I can always send again! I think 
>instead of filtering out ERR_MEM, we should somehow rework the whole conn->err 
>related code.

Yes, agree with you. But first strange thing it there is a change in 
netconn_addr (like in netconn_peer). I think the initial use of conn->err was 
to return fatal errors, to avoid some deadlocking case, like in netconn_recv 
(if you got an error, but didn't check conn->err, you could redo an 
netconn_recv, which wait forever because no other msg would be post by 
err_tcp)...

Other thing about error code, see https://savannah.nongnu.org/patch/?5960...
  
====================================
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 Goldschmidt Simon
Envoyé : mercredi 30 mai 2007 09:27
À : lwip-devel
Objet : RE: [lwip-devel] Comments about "low_level_output"



>  1/ What do you think that a "low_level_output" function should return
when all "buffers" are full? 
 
ERR_MEM seems good to me.
 
> 2/ Is it something you do in your ports to "block" inside
low_level_output to wait some space to send? (I don't think, but...) 
 
No.
 
> 3/ Isn't it something to document anywhere? I think, but where? I
thought to rawpi.txt... 
 
Yes!
 
> 4/ Should we have to "filter" such "temporary errors" inside do_xxx
functions? (It will add some code, and increase footprint, so, I don't like 
that) 
 
I think the real question is "why don't we allow a send if the previous send 
went wrong?"

That seemed strange to me when I first looked over the code. More, if I call 
netconn_addr() after a send that went wrong, I can always send again! I think 
instead of filtering out ERR_MEM, we should somehow rework the whole conn->err 
related code.

 
> My current workaround is to return ERR_OK in the place of ERR_IF in
this case (it's just affect my port, and, after all, a packet could always be 
lost in the network...) 
 
That works,  of course, but it's really a workaraound, not a solution.


Simon


_______________________________________________
lwip-devel mailing list
address@hidden http://lists.nongnu.org/mailman/listinfo/lwip-devel

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]