|
Hello Simon,
thank you for the positive clarification! That is good news.
Regards,
Michael
Am 29.01.2017 um 13:18 schrieb sg:
Michael,
You absolutely don't need to worry.
Those are only ideas and if that change really should come,
netconn API will either stay or be replaced by nearly equal API
calls which would be easy to replace...
Cheers,
Simon
Am 29. Jan. 2017, um 12:34, Michael
Steinberg < address@hidden>
schrieb:
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
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
|