patchlwIP - A Lightweight TCP/IP stack - Patches: patch #5914, Move sockopt processing into...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #5914: Move sockopt processing into tcpip_thread

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Thu 03 May 2007 06:55:51 PM UTC
   
 
Category:  None Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  goldsimon Open/Closed:  Closed
Planned Release:  None

Jump to the original submission

Mon 04 Jun 2007 09:05:23 AM UTC, comment #29: 

I think your patch doesn't build with LWIP_IGMP=1, due to a the "err" variable in line "err = EAFNOSUPPORT;". Do you have try to build it with? I can't, because I'm in a frozen release for my products, and because I think it will be restore like before when we will got the global mutex...

Frédéric Bernon <fbernon>
Group Member
Sat 02 Jun 2007 05:11:34 PM UTC, comment #28: 


> The general idea is to add in struct api_msg_msg, a new substruct "opt" in the union :


That would work but it has two disadvantages:
- struct api_msg_msg gets bigger
- members are added to struct api_msg_msg that are only used for sockets.

Also, to integrate that cleanly in the existing layout, we would have to create functions like do_setsockopt residing in api_msg.c which wouldn't work because they would have to access the struct lwip_socket defined in sockets.c!

Don't get me wrong, I don't think using tcpip_callback is the cleanest way to do it, but I also don't favour the other ways...

> Another thing I don't like with that, is the fact to have to communicate with tcpip_thread just for set options.


Neither do I , but it's the way it's solved for now, and I can't change it (as long as we don't move to mutex-locking, of course)!

I'm eager to on that, though. Only some bugs and patches left!

Simon Goldschmidt <goldsimon>
Group administrator
Sat 02 Jun 2007 12:53:04 PM UTC, comment #27: 

Sorry, I don't have find time for that. More, I think it will be so simple in the future socket layer (using the global mutex).

But even if it's closed, if I can propose you an alternative... The general idea is to add in struct api_msg_msg, a new substruct "opt" in the union :

struct api_msg_msg {
  struct netconn *conn;
  union {
    /* ... */
    struct {
      int s;
      int level;
      int optname;
      void *optval;
      socklen_t *optlen;     
    } opt; /* options */
  } msg;
};

it's enable to use tcpip_apimsg, like all others functions. Another possibility is to replace by the "union msg" by a "void * arg" to avoid to extend the api_msg_msg for each message type...

Another thing I don't like with that, is the fact to have to communicate with tcpip_thread just for set options. If you have to create a socket with 3 or 4 options, do a sendto, and close it, it's a little bit longer (and we know that each exchange with tcpip_thread have a real cost...).

But with the future socket layer... ;)

Frédéric Bernon <fbernon>
Group Member
Fri 01 Jun 2007 05:17:13 PM UTC, comment #26: 

OK, checked in my patch.

Since I think comment #25 was meant for another task, I'm closing this as done.

Simon Goldschmidt <goldsimon>
Group administrator
Tue 22 May 2007 09:10:05 PM UTC, comment #25: 

I will propose a patch tomorrow...

Frédéric Bernon <fbernon>
Group Member
Thu 10 May 2007 02:54:46 PM UTC, comment #24: 


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


I've done it, and I prepare a patch file for that. I will open another thread.

>Frédéric, did you make any progress with an alternative?


I have first to replace the table to propose an alternative. I hope send that this evening or tomorrow...

> 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 ;-)


Once done, I think I could test your patch. But like propose in comment #15, I think it's good...


Frédéric Bernon <fbernon>
Group Member
Thu 10 May 2007 11:22:07 AM UTC, comment #23: 

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 that.

- 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 ;-)

Simon Goldschmidt <goldsimon>
Group administrator
Mon 07 May 2007 07:09:00 PM UTC, comment #22: 

re comment #21:

That's one step in the right direction (reducing code footprint, I mean).

Still, we would have 2 mechanisms of doing the same thing (calling into tcpip_thread). If you want synchrone/asychrone you can still take the same mechanism and wrap it with a function/define waiting for a semaphore or mbox...

Simon Goldschmidt <goldsimon>
Group administrator
Sun 06 May 2007 08:36:14 PM UTC, comment #21: 

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;
};

err_t
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;
  api_msg_post(&msg);
  return conn->err;
}

static void
tcpip_thread(void *arg)
{
  //...
  case TCPIP_MSG_API:
  //...
      msg->msg.function(msg->msg.apimsg);
      break;
  //...
}

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


Frédéric Bernon <fbernon>
Group Member
Sat 05 May 2007 09:21:32 AM UTC, comment #20: 


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


Oh, and of course, it would make it a lot easier to experiment with locking the core from different threads instead of passing messages to one 'core'-thread!

Simon Goldschmidt <goldsimon>
Group administrator
Sat 05 May 2007 09:00:44 AM UTC, comment #19: 


>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 there.


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 receive...


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!

Simon Goldschmidt <goldsimon>
Group administrator
Sat 05 May 2007 12:38:32 AM UTC, comment #18: 

Frédéric Bernon wrote:

>
> Socket "problems" are mainly "lot" of parameters checking (not useful if you
> are sure about your parameters), and impossible to get a zero-copy for
> receive (adding a memcpy)... What else?


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

- Impossible to indicate that something is immutable (e.g. ROM) for TCP.

- All API funneled through same functions, so no possibility of linker removing unused ones on basis of which API function is called. setsockopt is the best but not only example. So a function like netconn_option() would be bad. netconn_option_ip, netconn_option_tcp, netconn_option_udp, etc. would be better.

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

- struct lwip_socket contents and file descriptor arrays.

If you correct all these, you have something very unlike the BSD API. With a non-standard BSD API.... well why not call the netconn API the non-standard API :-). 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 there.

> Your solution, to my point of view, is just a new and redundant
> "tcpip_apimsg" (synchrone call to tcpip_thread). Even, note that in current
> CVS, tcpip_callback is only used by PPP, and should have to be disable if no
> PPP interfaces is used...


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.

Anyway that thought is a general one, and I'm not necessarily trying to say we should start adopting the practice right now.

Jonathan Larmour <jifl>
Group Member
Fri 04 May 2007 08:34:56 PM UTC, comment #17: 

Ok, Simon, talk about that (even if we could open a separate task to this subject)  :)

If one day, we have lot of time to redesign lwIP API, to my point of view, I will never think to add something like the netconn layer, but I will just prefer to add some "non-BSD" functions to sockets API to add the zero-copy feature.

But I don't think to get time, and current "socket on netconn" architecture work, and not so bad, and not so slow: communication with tcpip_thread is stable, and except for some multithreading case, it's good.

Why, most of time, we talk to have an independant socket layer? I think it's because netconn users don't want to have extra code or a "longer" run time if they don't need it, and each socket feature add code they don't need. And I can understand that...

Socket "problems" are mainly "lot" of parameters checking (not useful if you are sure about your parameters), and impossible to get a zero-copy for receive (adding a memcpy)... What else?

To come back on this item: I don't think that starting now to add redundant code for "joingroup" and a different feature to communicate with tcpip_thread is the good thing to do, and it's not coherent with all others sockets functions (and, I like lwIP because it is simple and have a nice design). Your solution, to my point of view, is just a new and redundant "tcpip_apimsg" (synchrone call to tcpip_thread). Even, note that in current CVS, tcpip_callback is only used by PPP, and should have to be disable if no PPP interfaces is used... I would like to propose you a patch based on tcpip_apimsg, I think it would the same thing, except one or two details, but more coherent (always, to my point of view, of course). Ok for you ?

If you really prefer your solution, so, add LWIP_NETCONN options, and disable do_join_leave_group(), because "I don't want to increase my footprint for a function only used by netconn users !!!" :) It's a "joke", of course, but it's right.

That why I think that adding LWIP_SOCKETS & LWIP_NETCONN are really necessary. It's a good solution to let an "API common part" (for both layers), and to only add code necessary for the layer used. More, things like LWIP_LOOPIF_MULTITHREADING could be defined like ((LWIP_SOCKETS>0) || (LWIP_NETCONN>0)).

Last, about "who of us would use lwIP if there was another stack which is faster and dosn't cost much", you're right, but fast is not the only aim with lwIP: it can be small, and stable. In a previous item, we have talk about option to define if the user prefer to reduce his footprint, or to increase the speed of the stack. I also think we should add options for that. And I would like to get an option for tune the parameters checking: most of time, these checkings, like "if (conn == NULL) {" or "if (!sock)" are not "useful" (application level already check them).

Thank you Simon to spend time to read that :)


Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 06:50:50 PM UTC, comment #16: 


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

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2007 06:35:41 PM UTC, comment #15: 

Ok, it seems that igmp_joingroup & igmp_leavegroup calls are ok (even if I can test it yet), but it should be better to use use a ip_mreq struct for groupaddr parameters :

sock->conn->err = igmp_joingroup(netif_default, (struct ip_addr )&(((struct ip_mreq )optval)->imr_multiaddr.s_addr));


Else, about comment #11 & comment #14?


Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 04:54:06 PM UTC, comment #14: 

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

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

Are you agree with the fact that netconn & sockets, if one day we split them, will share most of the code of api_msg? So, if some part of api_msg has to be different for socket and for netconn, we will need something to tell if the user need such or such part ?

So, LWIP_SOCKETS could be used to tell in api_lib/api_msg if you have to include specific api_msg extension. And a LWIP_NETCONN should also be used do enable netconn specific functions.

In api_msg.c, we should get something like :

/*pseudo code*/
#if LWIP_SOCKETS
do_getsockopt()
{ ...
}

do_setsockopt()
{ ...
}
#endif

#if LWIP_NETCONN
do_netconn_nodelay( int enable) // by example
{ if ( enable) {
    msg->conn->pcb.tcp->flags |= TF_NODELAY;
  } else {
    msg->conn->pcb.tcp->flags &= ~TF_NODELAY;
  }
}
#endif


Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 04:35:44 PM UTC, comment #13: 

I've put together a new patch and tested it (although not the igmp part: don't know how to test).

Frédéric, can you tell me if this is right (the IGMP part)? I don't really know, since the netif address of the struct ip_mreq is not used, instead default_netif is used...

(file #12693)

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2007 03:41:56 PM UTC, comment #12: 


>That's why, to my point of view, an LWIP_SOCKETS option and a netconn_options() function is a better solution, but if you don't like it... :)



Jonathan wrote:

>In due course I'm sure it makes sense for netconn to also have a way to set options, although I wouldn't want to channel them all through a single function like BSD does.


I must say I agreee with Jonathan. For netconn API, I wouldn't put all options in one function but create more functions eliminating all the parameter-checking (set/getsockopt() are quite big...). An LWIP_SOCKETS options is not necessary, I think. If you don't use sockets, just don't include sockets.c in your app. As netconn API is always included, I think we wouldn't gain anything from such a define, or would we?

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2007 03:31:12 PM UTC, comment #11: 

You can call directly igmp_joingroup()/igmp_leavegroup() like in do_join_leave_group, but it will be redundant. If you decide to remove it, how netconn users can use IGMP?

That's why, to my point of view, an LWIP_SOCKETS option and a netconn_options() function is a better solution, but if you don't like it... :)

Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 03:15:30 PM UTC, comment #10: 


>Other thing: like this, I'm afraid you got a deadlocking case with IP_ADD_MEMBERSHIP & IP_DROP_MEMBERSHIP


Oh, you mean netconn_join_leave_group(), I see... Should I call igmp_joingroup()/igmp_leavegroup() directly or what would you propose?

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2007 12:43:03 PM UTC, comment #9: 

Other thing: like this, I'm afraid you got a deadlocking case with IP_ADD_MEMBERSHIP & IP_DROP_MEMBERSHIP (these options call netconn). If you don't like to add a LWIP_SOCKET & netconn_options,  don't forget to update this code...


Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 10:34:55 AM UTC, comment #8: 


>Yes it is like that, but when integrating setsockopt into api
>messages, we would have to introduce yet another type of api msg.


Yes, but you have already the communication layer with tcpip_thread   and it's ready if, "one day", a netconn user want to use it. And it  help to remain coherent with current sockets/tcpip_thread architecture, no ?

>Huh? What do you mean? I'm trying to make lwIP sockets API more
>thread-safe, if that's what you mean?


Ah, ok, I just want to be sure about that. Do you have see some special cases where a direct access is not "good" ? Because, most of time, it's only memory word access, right?

> If it's integrated directly into api_msg.c, then the code is

present for everyone (Jonathan)

Yes, but why not a LWIP_SOCKETS options? It could help to know if some code have to be use only for sockets users, and help to remain coherent with current design. What do you think about that? (after all, we have also add some defines to know if we are or not in ...MULTITHREADING)


Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 10:14:49 AM UTC, comment #7: 

IMHO tcpip_callback() is better here. If it's integrated directly into api_msg.c, then the code is present for everyone. With tcpip_callback() it's only present for those using setsockopt() (or for compilers that don't yet have sensible linking, the socket API at least).

This is one of the problems with the socket API (not just the lwIP implementation of it) in general. It pulls in all sorts of functionality because everything channels through the same small set of functions; even though that functionality is never needed.

Unofficially, someone can access PCBs if they disable tasking themselves temporarily, or use tcpip_callback themselves.

In due course I'm sure it makes sense for netconn to also have a way to set options, although I wouldn't want to channel them all through a single function like BSD does. But let's not worry about that now.

Jonathan Larmour <jifl>
Group Member
Fri 04 May 2007 09:49:20 AM UTC, comment #6: 


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


Yes, I think so, too. But I don't really want to introduce new netconn API functions as long as nobody uses them...

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


Yes it is like that, but when integrating setsockopt into api messages, we would have to introduce yet another type of api msg.

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


Huh? What do you mean? I'm trying to make lwIP sockets API more thread-safe, if that's what you mean?

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2007 09:36:05 AM UTC, comment #5: 


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




Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 08:09:28 AM UTC, comment #4: 

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

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?

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?

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!

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 May 2007 07:20:38 AM UTC, comment #3: 

Because all the sockets API use api_lib/api_msg, I don't think it's a so good idea to directly call tcpip_callback. I think it should be better to extend api_lib/api_msg (like for igmp by example)... It will also give possibility to be available to netconn API users...

Yes, no ?

Except that, what is the issue with "sockopt" you propose to fix ? Task https://savannah.nongnu.org/task/?6837 doesn't provide any informations...

Frédéric Bernon <fbernon>
Group Member
Fri 04 May 2007 06:35:12 AM UTC, comment #2: 


>Maybe I'm blind but shouldn't something be posting into the mbox?


No, you're not. But it seems like I am... Now you can see I didn't test it, yet, only compiled it as it should be a draft.

Now that you also think that's the right direction, I'll go on in that direction. (means I'll check it in after testing it)

Simon Goldschmidt <goldsimon>
Group administrator
Thu 03 May 2007 07:24:24 PM UTC, comment #1: 

Maybe I'm blind but shouldn't something be posting into the mbox?

Other than that I think it looks great.

Jonathan Larmour <jifl>
Group Member
Thu 03 May 2007 06:55:51 PM UTC, original submission:  

To achieve this, I propose simply calling tcpip_callback() and moving the processing of the options in lwip_setsockopt()/lwip_getsockopt() into dedicated functions called by tcpip_callback(). sock->conn->mbox can be used to wait for the callbacks to finish, as done for all netconn functions.

The only downside is we pull tcpip.h knowledge into sockets.c, but I think that's OK.

See attached patch.

Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #12693:  sockets.c_sockopt2.patch added by goldsimon (7KiB - text/x-patch)
file #12684:  sockets.c_sockopt.patch added by goldsimon (3KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by jifl (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-06-01 goldsimon StatusNone Done
        Open/ClosedOpen Closed
    2007-05-04 goldsimon Attached File- Added sockets.c_sockopt2.patch, #12693
    2007-05-03 goldsimon Attached File- Added sockets.c_sockopt.patch, #12684

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code