[lwip-devel] [patch #5914] Move sockopt processing into tcpip_thread

[Simon Goldschmidt]

Follow-up Comment #23, patch #5914 (project lwip):

While I think including the function pointer instead of a table index in the
message is a good way to reduce footprint, I think we should discuss that in
a separate thread.

Staying with _this_ problem:

- Frédéric, did you make any progress with an alternative?

- Most of the options in getsockopt() can be left in application thread, I
think, as long as we protect the reading of the variables using
SYS_ARCH_PROTECT(). There is the downside that on 16-bit-platforms another
thread might be interrupted while storing to a 32-bit variable and that
variable would have half the new value and half the old one resulting in a
wrong value. That can't be protected using SYS_ARCH_PROTECT() (as long as you
don't protect every variable in tcpip_thread context). And since getsockopt()
shouldn't be called too often, I suggest we still call into tcpip_thread for
that.

- Do we agree that the only open question is how to call the IGMP functions?
If so, I would check in the rest these days to have a suitable start at this
and make some progress to a thread-safe stack ;-)

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?5914>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/