On Thu, 2010-10-14 at 09:25 -0400, Dany Thiffeault wrote:
> Thanks Kieran.
>
>
> Well... a non-blocking call returning an error would be great for me
> if there is a connection problem. I could then detect an error when
> writing the packet and close the connection and shutdown some stuff
> for safety of people around the device.
"for safety"? That worries me!
> I have a device that is acquiring data and streaming everything on
> Ethernet. So, the majority of the time when streaming, the application
> is writing data on the Ethernet port. So, if I disconnect the Ethernet
> cable or another communication problem occurs that "hangs" the thread
> in the netconn_write function, I cannot detect it.
This is a common problem, but it's just the way that the sockets API and
TCP are designed: they try to be resilient to connection breakages and
hope that the connection comes back. I would suggest using a different
thread to monitor the link state (not through lwIP) and base your
decisions about connectivity on that.