[Top][All Lists]
[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
Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE : [lwip-devel] Comments about "low_level_output",
Frédéric BERNON <=