Hi Simon,
My tasks are organized like this : 1 - tcpip_thread ( internal thread for LWIP ) 2 - PPP + GSM AT commands, my own thread to coordinate PPP and AT commands to get connected ( this thread it's my own code, but it's also based on PPP thread from LWIP, I use SIGHUP, and other ways to coordinate and keep PPP activated. 3 - TCP connection, here I have just 1 netconn connection open, if I loose connection or my data application detects some failure, I reestablish the connection, sometimes even the GPRS connection.
So based on your questions, I'm not using threads for connection. And in my tests netconn_write does not block up to end of transmission, it's true only in cases that the buffer it's smaller then NET_SND_BUF size, if it's bigger, the remaing data it's queued but the semaphore at netconn_write it's realeased, and when this situation occur with the case that I had described ( the ACK came from network in a specific situation, the code that generate the EVENT to let application known about the transmission success, then I have the fail situation about semaphore and data corruption ) as the event it's optional to be "installed or not" the callback function, I can't see why there is a reson to call do_writemore inside that code, as it's not called for all situations of config.
If I cannot write while there is a second write at same time ( even not multithread, as I explained) how can I check that there is remaing information at transmission?
Another topic, I'm still with some issues related to semaphores, memp, and other kind of minor bugs, I had activated all status messages to understand the use of memory, but I can't see the main reason for this fails, any other suggestion to analyze are very welcome.
Best regards, Vinicius
Vinicius Bernardi wrote:
I didn't remove code from do_write
I remove this code below(<<<<<<<<)
As this code is dependent of the callback function to be registered.
And as I said, if there is 1 write bigger then the buffer happens, and the
second write happens, the status will be NETCONN_WRITE,
I'm not sure I understand: there cannot be one write under way and a second write "happening" - a socket or netconn may only be used from one thread at a time, and the first write does not return to your application code until it has finished (i.e. conn->state is not NETCONN_WRITE any more). (yeah it can heapen ) <<<<<<Could it be that your are using one netconn from multiple threads? NO I'm not using. <<<<<<<<
Also, you cannot remove the code commented out from sent_tcp() - it is required to execute writes that don't fit into the internal buffers in one block.
Even removing it, it is sending the remaing data from another part of code ( already tested ) |