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

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

About the problem to reduce footprint (due to the dispatch table), juste an
idea, easy to do, without breaking all the code: and if we replace the "type"
field in "api_msg", by directly the same type of function that the current
dispatch table? (in the pseudo code here, I have rename the "api_msg_decode"
by "api_msg_function", just because I think is clearer). Isn't it something
simple to do? Because, I always think we can describe "tcpip_apimsg" like a
"synchrone call to tcpip_thread" and "tcpip_callback" like a "asynchrone call
to tcpip_thread" :

typedef void (* api_msg_function)(struct api_msg_msg *msg);

struct api_msg {
  api_msg_function function;
  struct api_msg_msg msg;

netconn_send(struct netconn *conn, struct netbuf *buf)
  struct api_msg msg;


  msg.function = do_send;
  msg.msg.conn = conn;
  msg.msg.msg.b = buf;
  return conn->err;

static void
tcpip_thread(void *arg)

About comment #18: 

> With standard BSD API, impossible to get zero-copy for transmit either. 

Agree for TCP, but for UDP ? I'm not sure...

> select(). Look how much code is needed to handle the imposed API
requirements. Enough said. 

I'm agree, I don't like this, and I think it should be an option...


Reply to this item at:


  Message posté via/par Savannah

reply via email to

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