Nicolas Pinault a écrit :
Nicolas Pinault a écrit :
Yoav Nissim a écrit :
Pardon me for barging in... I have encountered the same issue about a
week or two ago.
Using select() would be the natural choice for performing multiple
non-blocking operations.
You can either:
1. Use select() in a single thread to perform both Rx & Tx (recommended)
2. Keep Rx and Tx threads locked and waiting on a select running in
another thread (in essence adding the locking mechanism that lwIP does
not support)
As with a single thread my application still does not work correctly, I
suspect there is a bug in my port.
I'd like to check some points :
I use a thread for MAC rx. This thread waits for MAC rx frames and
calls ethernetif_input().
This thread has a lower priority than TCPIP_THREAD_PRIO. Is this ok ?
My current port implementation is simple and when transmitting,
low_level_output() waits for the packet to be sent before returning
(wait on a semaphore set by Tx interrupt). Is this ok ?
There is no mutex between tx and rx functions. That is,
ethernetif_input() can be entered while low_level_output() is running
and vice-versa.
Is this a problem ?
What must be the application thread priorities ? Higher priority than
TCPIP_THREAD_PRIO ? Lower priority than TCPIP_THREAD_PRIO ?
Regards,
Nicolas
I have changed threads priorities, set bigger and more lwip buffers.
Things are getting better.
The strange thing is that tx is delayed when frames are received. The
more received frames, the higher the delay.
Vnc client sends a frame each time the mouse is moved. This generates
many frames. If I click on the update screen icon, screen content
frames are sent immediately by my application. If I move the mouse in
the client window (describes circles in the client window), then click
on the update screen icon, screen content frames are sent by my
application after seconds (number of seconds depends on the number of
circles described with the mouse).
I'm still investigating...
I finally got it !
After rereading lwip MAC port, lwip OS port, application. After adding
tons of traces. After compiling and launching many times... I got it.
I know why lwip locks.
The problem comes from the quantity of incoming packets.
Sending screen content request much time and many buffers. While
sending screen content my application does not read incoming packets.
So, when lwip buffers are full of incoming packets (pending for the
application to consume them), transmit is locked because of a lack of
buffers. And incoming packets are not consumed because my application
wants to transmit packets before doing anything else.
I now have to write correct code.
Thanks to all for your help.
Regards,
Nicolas
Nicolas
HTH,
Yoav.
On 11/01/10 9:46 AM, Nicolas Pinault wrote:
address@hidden a écrit :
Nicolas Pinault wrote:
Is this a threading problem ?
Yep, using a socket from more than one thread at the same time is
currently not supported.
Ok.
So, what do you recommend to asynchronously send and receive data
(with a socket).
Nicolas
Simon
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
|