select() should not block on write_fds for long, so I would agree that
something is not working properly.
That said, you do have to make sure that your output buffers are large
enough to take the screen updates you expect the system to maintain.
The porting and IF init code is the best place to start. AFAIK:
1. The call from your Rx thread should not call ethernetif_input()
directly. It should call netif->input() - which in turn is
initialized to tcpip_input() when you call netif_add().
2. Your output logic seems OK.
3. All input and output should be called from within the TCPIP thread.
Therefore actual input and output operations do not occur
simultaneously. Only queueing of operations occurs simultaneously.
4. The call to the your if_init/netif_add function should be done from
within TCPIP's thread context (using the callback given to tcpip_init())
Nicolas, please post your initialization code - the call to
netif_add(), who calls it, and your interface initialization function
(the 6th parameter in the netif_add() API)
Yoav.
p.s All of my comments are based on my experience with lwIP which is
by no means complete. I defer all my remarks to Simon, Kieran, et al...
On 12/01/10 10:31 AM, Nicolas Pinault wrote:
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
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
--
Yoav Nissim
Software Engineer, Software Tools Division
Jungo Software Technologies
Email: address@hidden
Web: http://www.jungo.com
Phone: +972-74-7212138
Fax: +972-74-7212122
Mobile: +972-54-2271315
|