Topic branch: rosuav/sockopt
Per Lance's suggestion, I've made a generic setsockopt() function. It works only with integers, so it's not suitable for SO_LINGER, which therefore should stay the way it is (linger() takes a magic parameter of -1), but it works for any of the simple boolean options.
As to shortcut functions, though, there are a few ways they can be done.
1) set_keepalive() always exists, even if SO_KEEPALIVE isn't available. If you call it when there's no SO_KEEPALIVE, it sets errno and returns failure. 2) set_nodelay() exists only if TCP_NODELAY is available. 3) setsockopt() itself is useless without the constants, and Stdio.TCP_NODELAY will exist only if TCP_NODELAY is available.
So in a Pike script, using setsockopt() requires either has_index() run-time checks or #if compile-time checks for the options you want; set_keepalive's model works easily if you know that the Pike version you're targeting supports it; and set_nodelay's model lets you treat older Pikes and systems without that feature the same way.
I'd rather make it as easy as possible on the Pike code. Which way makes more sense?
ChrisA
Chris Angelico wrote:
Topic branch: rosuav/sockopt Per Lance's suggestion, I've made a generic setsockopt() function. It works only with integers, so it's not suitable for SO_LINGER, which therefore should stay the way it is (linger() takes a magic parameter of -1), but it works for any of the simple boolean options.
You could add a void|mixed optval second argument which is suitably interpreted depending on the option at hand.
I'd rather make it as easy as possible on the Pike code. Which way makes more sense?
I would prefer the compile-time checks for efficiency reasons.
Just throwing this out there, some modules have the functions present regardless, and return a message or error code saying it isn't implemented if it wasn't compiled in. So another option is to have all the methods present, and either return a message or error code, or throw an exception, and let the programmer deal with it.
When you think about it, what is easier, to try something, catch the error and try an alternative, or to have an if statement to determine if the first exists and do the alternative if it doesn't. Really kind of the same thing....
Depends on what we prefer to do, I guess. Ruby tends to try and rescue (catch) the exception and try something different, but that may just be something preferred by most ruby programmers.
On Thursday, August 28, 2014 4:34 PM, Stephen R. van den Berg srb@cuci.nl wrote:
Chris Angelico wrote:
Topic branch: rosuav/sockopt Per Lance's suggestion, I've made a generic setsockopt() function. It works only with integers, so it's not suitable for SO_LINGER, which therefore should stay the way it is (linger() takes a magic parameter of -1), but it works for any of the simple boolean options.
You could add a void|mixed optval second argument which is suitably interpreted depending on the option at hand.
I'd rather make it as easy as possible on the Pike code. Which way makes more sense?
I would prefer the compile-time checks for efficiency reasons.
Lance Dillon wrote:
Just throwing this out there, some modules have the functions present regardless, and return a message or error code saying it isn't implemented if it wasn't compiled in.? So another option is to have all the methods present, and either return a message or error code, or throw an exception, and let the programmer deal with it.
All things considered, I would have a preference to have all methods present and accounted for, even if they do not work. And then, for maximum ease of use, choose to: a. Return a value which can indicate failure, but the programmer can choose to ignore if the failure is non-essential. b. Indeed have undefined constants which allow programming just like one does in C, which allows compile time decisions to except support for certain features.
When you think about it, what is easier, to try something, catch the error and try an alternative, or to have an if statement to determine if the first exists and do the alternative if it doesn't.? Really kind of the same thing....
Using exceptions forces the programmer to take rather explicit and verbose actions to accomodate in this case; so I'd prefer returncodes instead which can be ignored without a lot of fuss (and it avoids rather costly exception handling).
I think we should merge this, or at least a similar API. Any objections?
Arne
On 08/28/14 19:07, Chris Angelico wrote:
Topic branch: rosuav/sockopt
Per Lance's suggestion, I've made a generic setsockopt() function. It works only with integers, so it's not suitable for SO_LINGER, which therefore should stay the way it is (linger() takes a magic parameter of -1), but it works for any of the simple boolean options.
As to shortcut functions, though, there are a few ways they can be done.
- set_keepalive() always exists, even if SO_KEEPALIVE isn't
available. If you call it when there's no SO_KEEPALIVE, it sets errno and returns failure. 2) set_nodelay() exists only if TCP_NODELAY is available. 3) setsockopt() itself is useless without the constants, and Stdio.TCP_NODELAY will exist only if TCP_NODELAY is available.
So in a Pike script, using setsockopt() requires either has_index() run-time checks or #if compile-time checks for the options you want; set_keepalive's model works easily if you know that the Pike version you're targeting supports it; and set_nodelay's model lets you treat older Pikes and systems without that feature the same way.
I'd rather make it as easy as possible on the Pike code. Which way makes more sense?
ChrisA
On Thu, Feb 26, 2015 at 10:32 PM, Arne Goedeke el@laramies.com wrote:
I think we should merge this, or at least a similar API. Any objections?
Haven't heard anyone else's views on this, which suggests that nobody's particularly bothered one way or the other. Which version of the API do you want? Dedicated functions for each job, or a thin wrapper around setsockopt() itself?
ChrisA
Chris Angelico wrote:
On Thu, Feb 26, 2015 at 10:32 PM, Arne Goedeke el@laramies.com wrote:
I think we should merge this, or at least a similar API. Any objections?
Haven't heard anyone else's views on this, which suggests that nobody's particularly bothered one way or the other. Which version of the API do you want? Dedicated functions for each job, or a thin wrapper around setsockopt() itself?
What about: a. A primary thin wrapper around setsockopt(). b. Some secondary convenience functions for people unfamiliar with setsockopt(2) only for those options which are commonly used.
On Tue, Mar 10, 2015 at 8:17 PM, Stephen R. van den Berg srb@cuci.nl wrote:
Chris Angelico wrote:
On Thu, Feb 26, 2015 at 10:32 PM, Arne Goedeke el@laramies.com wrote:
I think we should merge this, or at least a similar API. Any objections?
Haven't heard anyone else's views on this, which suggests that nobody's particularly bothered one way or the other. Which version of the API do you want? Dedicated functions for each job, or a thin wrapper around setsockopt() itself?
What about: a. A primary thin wrapper around setsockopt(). b. Some secondary convenience functions for people unfamiliar with setsockopt(2) only for those options which are commonly used.
aka "both"? Sure! Doesn't bother me! :)
ChrisA
Chris Angelico wrote:
What about: a. A primary thin wrapper around setsockopt(). b. Some secondary convenience functions for people unfamiliar with setsockopt(2) only for those options which are commonly used.
aka "both"? Sure! Doesn't bother me! :)
Yes, but be reluctant in adding convenience functions (only for the real common ones), and be comprehensive in the setsockopt interface.
a. A primary thin wrapper around setsockopt(). b. Some secondary convenience functions for people unfamiliar with setsockopt(2) only for those options which are commonly used.
aka "both"? Sure! Doesn't bother me! :)
I like the convenience functions because then you don't have to bother about to see if the constants or functions are there. I'd like to think think they should always be there, even if the functionality isn't there on this system.
Mirar @ Pike developers forum wrote:
a. A primary thin wrapper around setsockopt(). b. Some secondary convenience functions for people unfamiliar with setsockopt(2) only for those options which are commonly used.
aka "both"? Sure! Doesn't bother me! :)
I like the convenience functions because then you don't have to bother about to see if the constants or functions are there. I'd like to think think they should always be there, even if the functionality isn't there on this system.
Well, ok, but then provide a list of functions you'd expect to be there. IMO, not all of them are useful to have access to via convenience functions.
So far people only seem to have used KEEPALIVE and NODELAY? (And linger?)
I merely meant I don't like functions to vanish just because the underlaying OS doesn't support them. I'd rather have the return error.
I'm not sure what other flags are useful or can be used. FASTOPEN? REUSEPORT? buffer size settings?
Mirar @ Pike developers forum wrote:
So far people only seem to have used KEEPALIVE and NODELAY? (And linger?)
I merely meant I don't like functions to vanish just because the underlaying OS doesn't support them. I'd rather have the return error.
I'm not sure what other flags are useful or can be used. FASTOPEN? REUSEPORT? buffer size settings?
Adding more convenience functions later is easy. I'd say we provide for the common set first: keepalive, nodelay and reuseport. Then, if someone actually finds himself using the more obscure ones, they can then send in a feature request for yet another convenience function.
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Chris Angelico -
Lance Dillon -
Mirar ＠ Pike developers forum -
Stephen R. van den Berg