This is basically a bunch of stupid questions due to not having had
enough time to study the code base in detail, but here goes...
I am looking at using lwip for an OS-less application. The application
itself is a single-threaded client, but the event-driven model of the
raw API (as far as I understand it) seems to match it poorly, so I have
been investigating the netconn and sockets APIs.
As far as I understand it, this requires multithreading, which isn't a
problem -- a trivial thread scheduler is easy enough to implement. The
question is, however, what capabilities that lwIP expects. In
particular, the easiest form of scheduling is to have only two threads,
the lwIP tcpip thread and the application thread, with the tcpip thread
running with absolute priority. The tcpip thread would be woken up by
interrupts (from the timer or the NIC) and by the application thread
blocking.
Can anyone think of any locking gotchas in this scenario? Similarly,
what would be the simplest implementation of the necessary locking
primitives that one can imagine? I don't know if simply enabling and
disabling interrupts would be sufficient.
-hpa
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
