On Wed, 2009-05-13 at 11:25 +0200, ncoage wrote: > > > I thought about that solution, but my application is more complex. > > > There are three tasks, each of them communicates with his own serial > > > port. When new data come from TCP, I check specific flag, which > > > determines wich task (serial port) must get rest of the data frame. > > > > Where do you get this flag from? > > From TCP data, in callback_function I receive netbuf, so I can see all > data. The value of particular byte determines where the rest of the > TCP data must go.
In that case I would just keep a list of connections and which task they should go to, so you don't have to look at the TCP data, and can route the connection in the case where there is no data. This assumes that a single connection always routes data to the same thread, but I'd hope that is the case. It sounds like at the moment you are reading from the connection in two different threads (once to get the flag, once to get the rest of the data). This is not supported unless you are protecting the connection with locks. You could end up with the two tasks trying to read simultaneously. The other thing that worries me about the way you have structured things is what happens if the chunk of data delivered to the callback does not have the flags byte in it. It sounds like you might be assuming that TCP will not split the data stream arbitrarily, but it can do this however it likes. i.e. It could deliver the data in two chunks: one containing the flag and some of the data, and one containing the rest. How do you protect against this? The most reliable way to implement what you describe would be for the callback connection to read all the data, reassemble and buffer it as necessary until it has assembled an entire application-level unit, then put the data (rather than the connection) on a queue and send them to the other task. The other task would then not need to use lwIP at all, and all the lwIP access would be done from one task (in the callback). Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
