Re: [lwip-users] netconn - using in different tasks

[Kieran Mansley]

On Wed, 2009-05-13 at 12:19 +0200, ncoage wrote:
> Thank you for your reply. I need more time to analize what you wrote :).
> But now I have a question, you wrote:
> 
> > 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).
> 
> I hope I understood you. The scenario is: I get new data from TCP, I
> put them to (exact) queue, another task reads data and send them to
> serial port. Now the task waits (blocks on semaphore) for reply from
> serial port and forms a reply to tcp. If I dont have a netconn in a
> the task, how can I send reply by TCP?

Ahh, OK, I didn't realise you needed to write data too.  In that case I
would keep all netconn accesses in the task.  The sequence would be
something like this:

1) you get a netconn_callback on a connection: look up in your own list
which task is responsible for that connection and send it a message
(e.g. via a queue) to say this connection needs attention.  You can
include details from the callback, e.g. what type of event it is, but
you shouldn't need to read or write from/to the netconn in the callback
to do any of this.

2) the task then pulls things off this queue, and reads (or whatever)
from its netconn, and does whatever it needs to with the data.  If len=0
when it reads, it can close it.

3) if the task needs to send data, it can do so directly as it won't be
conflicting with the callback as the callback doesn't touch the netconn
- only forwards the callback details to the appropriate task.

Kieran