Re: [lwip-users] Implementing sys_arch on lwip 1.3.2

[Simon Goldschmidt]

Luca Ottaviano <address@hidden> wrote:
> However the project started a while ago and now I'd like to
> finish it as soon as possible.

Then that's a good reason not to upgrade now :-)

> > From what I understand, you implemented your driver in the tcpip_thread
> and are blocking on a semaphore. This is not a good idea.
> 
> The EMAC driver is plugged into the ethernet thread using
> low_level_input() and sometimes it blocks waiting for input from the
> hardware. Such blocks are not handled using sys_sem_wait().
> The ethernet thread and the tcpip thread only communicate through
> messages, don't they? In this case I don't think I'm ever blocking the
> tcpip_thread.

OK, so if you are not blocking the tcpip_thread, timeouts should not be 
affected.

Having your own ethernet thread, you may block on a semaphore as long as you 
want: timeouts should not be handled from the ethernet thread, only from the 
tcpip_thread (lwIP timeouts should only be used inside the tcpip_thread, if you 
need timeouts in other threads, you have to implement them on your own!).

Then, once the ethernet thread has received a complete packet, pass it to the 
tcpip_thread using tcpip_input(). This way, the tcpip_thread should never block 
on a semaphore for too long (since it always has timeouts to process) and be 
interrupted by an incoming packet.

Being like that, I do not understand why waiting in the driver (which is not 
running in the tcpip_thread, like you said) should prevent the timeouts in 
tcpip_thread from being processed. This would mean that using a semaphore in 
thread A would influence the semaphore used in thread B.

Simon
-- 
NEU: FreePhone - kostenlos mobil telefonieren!                  
Jetzt informieren: http://www.gmx.net/de/go/freephone