[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] Multi-Threaded netconn API TCP application
From: |
Sylvain Rochet |
Subject: |
Re: [lwip-users] Multi-Threaded netconn API TCP application |
Date: |
Sun, 20 Sep 2015 20:52:25 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Hi Pirvu,
On Sun, Sep 20, 2015 at 02:05:38PM +0300, Pîrvu Mihai wrote:
> Hello guys, I'm sorry if this was posted before, but i couldn't find an
> answer, so I'm gonna post here in search of one.
>
> I want to create a simple multi-threaded TCP server, that handled each new
> connection on a separate thread. The listener thread will listen on the
> "main" thread, and every connection will create a new thread, that will
> communicate with the session created.
>
> The code I wrote is here: http://pastebin.com/zUuTtfL0
>
> I have dug a little into the lwip API to see how netconn_accept works and I
> saw that it blocks until the "not_empty" semaphore frm the "acceptbox"
> mailbox has something in it.
>
> Now, every time this happens, I create a new thread and the session
> creation is done there, and I block the main thread using the "semaphore"
> variable, so a new connection doesn't happen while I still proces the old
> one.
>
> Now, the problem is pretty much this:
> - I connect the first client, it works just fine
> - When ANY second client tries to join, it automatically gets disconnected
> and the server's console prints: Disconnected: 1, so netconn_recv doesn't
> return ERR_OK.
Could you share your MEMP_NUM_TCP_PCB, MEMP_NUM_NETCONN, MEMP_NUM_NETBUF
values ? It looks like you don't have enough of them.
> So my question is:
> - How can I create this multi-threaded enviroment so each client is
> processed in a different thread?
> - Also, what am I doing wrong in my current setup ?
>
> PS: The application runs on Linux atm, using lwip 1.4.0 (last stable one),
> the unix port from contrib directory and the clients connect using netcat
> <ip> <port>.
The only lwIP constraint on netconn control block is that netconn
functions are only thread safe against the core, they are not
reentrant, so you cannot share the control block between thread without
locking.
Why are you not processing the new TCP session in the current thread and
having your create_thread() just waiting on accept for a new incoming
session ? This will solve any issue about control block locking between
threads.
Sylvain
signature.asc
Description: Digital signature