lwip-devel
[Top][All Lists]
Advanced

[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: Fri, 04 May 2007 18:50:50 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

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

>but it should be better to use use a ip_mreq struct for groupaddr parameters
:

You're right, of course. My implementation relies on the current layout of
the struct ip_mreq. Shame on me!

>I will look the igmp part, but not before Wednesday (weekend, vacation,
holidays, yes!!! Is it possible to you to wait before commit that?).

Of course it is, I don't want to press on this!

>But, you don't answer to comment# 11 first part. 

I wouldn't remove the netconn code, and yes, the code will be redundant. But
that's because do_join_leave_group() posts to the mbox, which it mustn't when
called from inside setsockopt().

To be honest, I think I still don't really get what you're up to in comment
#14. Do you mean if someone is only using the sockets API,
do_join_leave_group() could be left out by those defines? Because if so, it
was a little confusing: LWIP_SOCKETS is not needed: if you use sockets API
setsockopt is included, if you don't, it's not included...?

But to get rid of redundant code, we could still implement another function
which is given the netconn, join_leave flag and struct ip_mreq. That way,
both setsockopt() and do_join_leave_group() could use this function. Not that
fast because of another function call, but those functions are not used that
often, are they? If we did this, we _could_ need a define like LWIP_NETCONN.
But then again, good compilers don't link functions that are never called...

What do you think?

-- 
Of course the best solution (in my opinion, and I don't seem to get tired in
stating it) would be to create a socket layer that doesn't depend on the
netconn API. This would mean redundant code for users who use both APIs, but
who does? :-)
I think if we have to compete with other stacks (and we do, don't we? who of
us would use lwIP if there was another stack which is faster and dosn't cost
much?), a fast socket api is an important thing to have!

    _______________________________________________________

Reply to this item at:

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

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





reply via email to

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