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: Frédéric Bernon
Subject: [lwip-devel] [patch #5914] Move sockopt processing into tcpip_thread
Date: Fri, 04 May 2007 09:36:06 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

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

>Hm, task #6837 and this patch are the same thing, I just wanted
>to send the patch here instead of to the task... maybe that was
>wrong...
No, it's good (even if I think it's "better" to directly open a patch item,
and not a task), but I just didn't understood the problem...

>Directly calling tcpip_callback might really not be that good,
>but I'd figth the argument of making this available to netconn
>API users. Socket options are for sockets, and we don't have any
>corresponding thing in netconn API, do we?
sockopt are just functions to access to internal lwIP options (most are at
"raw" level), so, if the issue if for thread-safe, I suppose it is also true
for netconn, right? And I suppose that a netconn user directly access to pcb
fields if he need these optiions?

>To me, this is another indication of the downside of having 2
>sequential APIs with one basing on the other: Since netconn API
>doesn't need sockopts, we can either add netconn API code which
>isn't used or call tcpip_callback() directly. Splitting the 2
>APIs would be better in that case. But this is another
>discussion, isn't it?
About "Since netconn API doesn't need sockopts", see last remark. But about
having 2 sequential API, I pretty agree with you, but even if we only use
socket layer and improve it to get same features like "zerocopy", and so,
don't use api_lib functions, the api_msg part will be the same I think... no?
But yes, it's another discussion...

>So we can either leave it like it is (setsockopt calling
>tcpip_callback() directly) or create something like
>netconn_callback() which simply calls tcpip_callback() maybe
>with automatic mbox synchronization). I'd vote for the direct
>call, though!
I thought that something like netconn_options() should be nice, but, because
I only use sockets, it's not a problem, but what think netconn users about
that? Is it really good to let them directly access to pcb ? 

About "calls tcpip_callback() maybe with automatic mbox synchronization",
isn't it finally the same thing that tcpip_apimsg ?

Can you tell me more about the issue you want to fix ?





    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/





reply via email to

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