|
From: | Enrico Murador - Research & Development - CET |
Subject: | Re: [lwip-users] Global reference to pbufs |
Date: | Mon, 16 May 2011 14:41:33 +0200 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 |
Ok. I placed these "checks" since my first tries with lwip, after I found that I was trying toThis is all a bit of an API violation, so I wouldn't do it that way. close a pcb that was already deallocated... All the code for catching the pcb closure was already there, but maybe there was some "hole" in my program flow... Ok. So, there are three "catch-points": application close, receive callback with NULL data,The PCB should remain valid after you have accepted it until either (i) the application closes it (and so you should already know about this); or (ii) the stack closes it (e.g. because it receives a reset from the other end) and it will then call your tcp_err() callback (I think, from memory, so worth checking) to tell you about this. If you use this callback to update your application state then you should find that the PCBs you are referencing are always valid. error callback... All my TCP handling is placed in a single "thread" so, provided that I will not try to send data on aBe careful about the context you are using to access these PCBs. For example, if you are closing connections from the accept callback (as described above) this will be in the context of whatever is executing the stack; you need to make sure that other contexts aren't also using that PCB to send data. "just deallocated" pcb reference (checking reference validity in the send routine), there should be no problems, right? This leads to the other question regarding tcp_write(): is it legal to call tcp_write() (and eventually also tcp_output()) for a pcb, outside of callbacks, regardless of the pcb actual state? Thank you Enrico |
[Prev in Thread] | Current Thread | [Next in Thread] |