[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: Sat, 05 May 2007 09:00:45 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20070309 Firefox/

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

>I could argue the converse - the whole api_lib/api_msg structure could be
turned around and replaced with tcpip_callback()s. Then underlying
functionality is only included if used. Right now, because of the dispatch
table it's always all included.

That would be a good idea! That way, tcpip_thread() would get smaller and we
wouldn't have to fit everything into the struct api_msg!

OK, about sockets, I think I'll drop the talking about changing it from
netconn api to directly accessing the stack :-( We would get lots of
redundant code... And I can see noone here wants to drop the netconn api :-)

>With a non-standard BSD API.... well why not call the netconn API the
non-standard API :-).

Because... it does have nothing to do with sockets, except for some similar
function names :-)

>I'm only half-joking - if there was an official way within the sockets
implementation to get the underlying netconn, we would be most of the way

Huh? What do you mean? Something like lwip_sock_get_netconn()? Not so bad...
You could get a callback event that one of your sockets has data to

Talking about select: This should generally be an option, I think. Some of
our applications don't even use select or set/getsockopt. And while
set/getsockopt can easily be left out by the linker, without select,
event_callback can be significantly smaller!


Reply to this item at:


  Nachricht geschickt von/durch Savannah

reply via email to

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