Figured out why I am hitting this issue. In the partial write case, the
write_offset is not reset back to zero. This causes the "already writing or
closing" assert in the next lwip_write() or lwip_close(). Once I set this
back to zero like this
diff --git a/lib/lwip/src/api/api_msg.c b/lib/lwip/src/api/api_msg.c
index 0a7edfe..2160766 100644
--- a/lib/lwip/src/api/api_msg.c
+++ b/lib/lwip/src/api/api_msg.c
@@ -1239,6 +1239,7 @@ do_writemore(struct netconn *conn)
/* partial write */
err = ERR_OK;
conn->current_msg->msg.w.len = conn->write_offset;
+ conn->write_offset = 0; /* reset this back to zero */
km_printf("partial write\n");
}
} else
things look to be working fine. Is this a known bug?
Thanks,
Alhad
On Mon, Oct 12, 2015 at 2:02 PM, Alhad Palkar <[email protected]> wrote:
>
> I tried using the SO_SNDTIMEO. Here is what I am seeing.
>
> 1. i create a socket using lwip_socket(AF_INET, SOCK_STREAM, 0) and then
> connect using lwip_connect()
> 2. set the SO_SNDTIME0 to 1s using lwip_setsockopt(socket, SOL_SOCKET,
> SO_SNDTIMEO, &timeout_int, sizeof(timeout_int))
> 3. then start sending data as follows
>
> while(err > 0) {
> err = lwip_write(socket, buffer, size);
> }
>
> I see that I hit the timeout condition in the 2nd to last transfer
>
> lwip_send(0, data=0x20A72D78, size=86264, flags=0x0) <--- this is the
> packet that times out
> ...
> *so_sndtimeo <-- added these printouts to check the condition I am hitting*
> *partial write*
> lwip_send(0) err=0 written=67348
>
> lwip_send(0, data=0x20A8348C, size=86264, flags=0x0) <--- the last packet
> that causes the assert
> panic: already writing or closing <--- we hit this in do_write() (
> api_msg.c:1360)
>
>
> Some questions;
> 1. Does that mean I cannot call lwip_write() after timing out on a
> previous call to lwip_write()?
> 2. Can I use the fact that the size returned by lwip_write() < total
> buffer size as an indication that our transfer timed out?
>
> Thanks,
> Alhad
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Oct 12, 2015 at 1:16 PM, Joel Cunningham <[email protected]>
> wrote:
>
>> It's a great trick, hopefully others can leverage it as well :)
>>
>> I'm not sure what I'd do without it. Having select() and non-blocking
>> sockets operate as the blocking construct of a server's event loop is
>> essential for managing multiple connections in a high performance manner.
>>
>> Joel
>>
>> On Oct 12, 2015, at 02:19 PM, Sylvain Rochet <[email protected]>
>> wrote:
>>
>> Hi Joel,
>>
>> On Mon, Oct 12, 2015 at 07:10:39PM +0000, Joel Cunningham wrote:
>>
>> 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.
>>
>>
>> I really like this trick. It remembers myself of the well known wake up
>> pipe I explained here[1], but using the loopback to do so in lwIP is
>> very very clever :-)
>>
>> Sylvain
>>
>> [1] http://lists.gnu.org/archive/html/lwip-devel/2015-09/msg00028.html
>> _______________________________________________
>> lwip-users mailing list
>> [email protected]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> [email protected]
>> https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>
>
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
