You can use SO_SNDTIMEOUT, which should work on LwIP 1.4.1. I have used it in
my port with LwIP 1.4.1, so possibly there's a problem with your port?
I've also written applications that used non-blocking sockets and select to
achieve a similar behavior of having blocking I/O that can be canceled. The
trick here is adding a second socket to the read FD set in select and then set
select to block until your write or read is ready. This second socket is bound
to the loopback address. When you want to cancel the blocking select from
another thread, simply send a datagram to the additional socket, which will
return the select call. Then you can detect that a cancel/wakeup happened
because the second socket is marked as ready.
Joel
On Oct 12, 2015, at 12:45 PM, Alhad Palkar <alhadpal...@gmail.com> wrote:
Thanks. Is there anyway around lwip_write blocking forever?
On Mon, Oct 12, 2015 at 7:44 AM, Joel Cunningham <joel.cunning...@me.com> wrote:
LwIP doesn't support this kind of threading model. Multiple threads can
not perform simultaneous operations (read+write, write+close, etc.) on the same
socket. The main limitation is that the netconn only has a single semaphore
for blocking the calling thread when entering the core context.
On the master branch there is support for this model but the feature is in
alpha state (see LWIP_NETCONN_FULLDUPLEX). In LwIP 1.4.1, this is not supported.
Joel
On Oct 10, 2015, at 12:29 AM, alhadpalkar <alhadpal...@gmail.com> wrote:
I am using branch 1.4.1 of lwip. I have a thread that connects to a remote
server and writes data to it using lwip_write(). Sometimes this hangs
indefinitely. Looks like its waiting on the op->completed semaphore which
never gets signaled.
I tried using the SO_SNDTIMEO socket option, but that just causes panics in
my system. So I tried another approach where I use a watchdog that detects
this hang and calls lwip_close(). But it looks like LWIP doesn't like it. I
hit this assert
netconn_free(struct netconn *conn)
{
LWIP_ASSERT("PCB must be deallocated outside this function", conn->pcb.tcp
== NULL);
...
}
On debugging further it looks like we end up getting the ERR_INPROGRESS in
do_delconn().
do_delconn(struct api_msg_msg *msg)
{
/* @todo TCP: abort running write/connect? */
if ((msg->conn->state != NETCONN_NONE) &&
(msg->conn->state != NETCONN_LISTEN) &&
(msg->conn->state != NETCONN_CONNECT)) {
/* this only happens for TCP netconns */
LWIP_ASSERT("msg->conn->type == NETCONN_TCP", msg->conn->type ==
NETCONN_TCP);
km_printf("err in progress\n");
msg->err = ERR_INPROGRESS;
...
}
so we never end up cleanup up the pcbs which leads to this assert.
Is there a way around this?
--
View this message in context:
http://lwip.100.n7.nabble.com/lwip-close-doesn-t-work-when-lwip-write-hangs-tp25191.html
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
