[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Handle multiple connections using netconn API?

From: address@hidden
Subject: Re: [lwip-users] Handle multiple connections using netconn API?
Date: Fri, 19 Nov 2021 18:05:05 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1

Am 19.11.2021 um 17:38 schrieb Grant Edwards:
For the past few days, I've been trying to figure out the netconn API
equivalent for select/poll, and I haven't been able to come up with

How does a single server thread handle multiple TCP or UDP
"connections" using the netconn API?

If you use a callback to wake the server thread, how do you avoid a
race condition when data arrives just after it has serviced all the
connections but before the server thread blocks?

Handling the recv data in the callback seems like a bad idea, since
that presumably is done in the tcpip thread's context. Handling the
recv data may take a considerable amount of time and needs to be done
at a low priority so that it doesn't interfere with other
time-critical traffic.

Isn't there some way to handle this without switching to the socket

Of course there is a way: "just" implement the same callback + select
behaviour as in the socket API. This is, however, not included in the
lwIP code, you'll have to do that yourself.

In theory, we could probably move the callback/select code from the
socket layer to the netconn layer. However, since noone has requested
this yet, noone worked on this, yet.


One answer is to create a server thread for each new connection, and
then use blocking recv calls. But, that's not possible in my RTOS:
threads can't be created dynamically. They have to be declared
statically at compile time. [Yes, that's a pain.]

In my system sys_thread_new() doesn't actually "create" a thread. It
searches the static table of threads and starts the thread with a
matching entry point.



lwip-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]