NutThreadYield() in NutTcpReceive()

"Vladimir Isaev" <[email protected]>
Newsgroups gmane.comp.hardware.microcontrollers.ethernut
Organization STC Metrotek, St.Petersburg
Message-ID <[email protected]>
Hi!

In our project we use the Nut/Net TCP stack for a small HTTP server
implementation. It was noticed it works very slow due to current
NutTcpReceive() implementation: every time it is invoked it calls
NutThreadYield() just at the very beginning, yielding the time to
all other threads before it finally reads the next piece of data.
Thus, when the program wants to read a lot of small pieces of data
from a TCP stream (for instance, by calling fgets() on the stream),
then it yields the CPU to other threads *for every char* dramatically
slowing down the process.

Finally, we have decided to remove the NutThreadYield() call from
NutTcpReceive() (and NutTcpSend() too). With this patch calling
fgets() on a TCP stream works much faster. As to the yielding of
CPU time, it is possible (and resonable) to call NutThreadYield()
at a higher level, outside of TCP stack, without forcing a yield
on every send/receive operation, isn't it?

Index: nut/net/tcpsm.c
===================================================================
--- nut/net/tcpsm.c     (revision 6229)
+++ nut/net/tcpsm.c     (working copy)
@@ -884,7 +884,6 @@
     if (sock == NULL) {
         return -1;
     }
-    NutThreadYield();

     switch (sock->so_state) {
     case TCPS_LISTEN:
Index: nut/net/tcpsock.c
===================================================================
--- nut/net/tcpsock.c   (revision 6229)
+++ nut/net/tcpsock.c   (working copy)
@@ -536,7 +536,6 @@
     /*
      * Check parameters.
      */
-    NutThreadYield();

[email protected]
-    NutThreadYield();
     /*
      * Check parameters.
      */

-- 
Vladimir Isaev
STC Metrotek
St.Petersburg
+7 (812) 340-0118
http://metrotek.spb.ru
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.