Re: [lwip-users] lwip_connect locks tcpip_thread when trying to connet to an inactive port

[Jonathan Larmour]

Luca Coppolaro wrote:
> 
> I traced the execution and those are the relevant steps:
> - (context: my SYS task) tcpip_apimsg post a message to execute do_connect
> - (context: my SYS task) tcpip_apimsg wait for a signal on the semaphore
> - (context: TCPIP task) message is fetched and do_connect is called
> - (context: TCPIP task) do_connect calls tcp_connect that does NOT send
> a signal on the semaphore, the signal will be sent from do_connected or
> err_tcp (see comments in do_connect)
> - (context: TCPIP task) destination is unreachable, and many retry are done
> - (context: TCPIP task) err_tcp is called when the max retry number is
> reached
> - (context: TCPIP task) err_tcp calls execute the macro API_EVENT
> because conn->recvmbox is not null
> - (context: TCPIP task) API_EVENT calls event_callback
> - (context: TCPIP task) event_callback calls sys_sem_wait and wait for a
> signal on the semaphore

It should not be blocked waiting (unless there's another thread around
which locked it). When socksem and selectsem are created in
lwip_socket_init, they are created with a value of 1. Is your port
respecting that?

> Then:
> - task SYS is waiting for a signal (it should arrive from err_tcp)
> - task TCPIP is waiting for a signal
> 
> Who is supposed to send the signal to TCPIP task?????

It happens later in err_tcp().

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine