[Top][All Lists]

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

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

From: Simon Goldschmidt
Subject: [lwip-devel] [patch #5914] Move sockopt processing into tcpip_thread
Date: Thu, 10 May 2007 11:22:07 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20070309 Firefox/

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

- 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:


  Nachricht geschickt von/durch Savannah

reply via email to

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