Am 29. Jan. 2017, um 12:34, Michael Steinberg <
Hi guys,
for my private work with lwip I ended up using NO_SYS=1 and rolling my
own thread and api based upon the low level interfaces. But now I'm in a
situation where I have to use the tcpip thread and am left with either
the socket api or the netconn api. In my personal opinion, the bsd
socket api does not really blend well into the embedded environment, at
least if you're running the system on OS's where not everything is
considered a file. I'm constantly in a situation where I can't
synchronize accesses to the socket, since the select call only knows the
lwip part of the world. So my natural course of action is to using the
netconn api, which gives the opportunity to do manual synchronization
with other parts of the target software and flexible sleeping due to the
callbacks it provides.
But on the other hand I read about people's opinions that netconn should
be deprecated or rather be considered an implementation detail, which I
cannot really understand due to the reasons given above. My question is,
will the api stay stable, or at least stay "there", even if it evolves?
I have the feeling that I might spend my time using a sinking ship. Also
I want to express my vote to "please keep an event based/callback based
api" with this.
Regards,
Michael
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users