On Thu, Nov 28, 2013 at 03:13:53PM +, jb wrote:
j But I don't understand why you find ksize()/malloc_usable_size() dangerous.
j ...
j
j The original crime is commited when *usable size* (an implementation detail)
j is exported (leaked) to the caller.
j To be blunt, when a caller requests
On 28 Nov 2013, at 15:13, jb jb.1234a...@gmail.com wrote:
Luigi Rizzo rizzo at iet.unipi.it writes:
...
But I don't understand why you find ksize()/malloc_usable_size() dangerous.
...
The original crime is commited when *usable size* (an implementation detail)
is exported (leaked) to
On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
On Thu, Nov 28, 2013 at 03:13:53PM +, jb wrote:
j But I don't understand why you find ksize()/malloc_usable_size()
dangerous.
j ...
j
j The original crime is commited when *usable size* (an implementation
On 11/29/13, 7:26 PM, Daniel Nebdal wrote:
On Fri, Nov 29, 2013 at 11:59 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
On Thu, Nov 28, 2013 at 03:13:53PM +, jb wrote:
j But I don't understand why you find ksize()/malloc_usable_size()
dangerous.
j ...
j
j The original crime is commited
Hello,
since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to
share the same port and possibly listening ip, you would expect if you bind
two daemon with such options to same port to see the same traffic on both!
This is not the case today.
Only multicast sockets seem to have
On Fri, Nov 29, 2013 at 1:04 PM, Ermal Luçi e...@freebsd.org wrote:
Hello,
since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to
share the same port and possibly listening ip, you would expect if you bind
two daemon with such options to same port to see the same traffic on
On 11/29/13, 8:04 PM, Ermal Luçi wrote:
Hello,
since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to
share the same port and possibly listening ip, you would expect if you bind
two daemon with such options to same port to see the same traffic on both!
this is not how I
On Nov 29, 2013, at 4:04 AM, Ermal Luçi e...@freebsd.org wrote:
Hello,
since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to
share the same port and possibly listening ip …
These flags are used with TCP-based servers.
I’ve used them to make software upgrades go more
Well seems Dragonfly has some version of it already from commit [1].
In FreeBSD there is the framework for this with by defining PCBGROUP.
Also the explanation of it at [2] and [3].
It can achieve approximately the same features of SO_RESUSEPORT of linux.
The only thing missing is the marketing
On Fri, Nov 29, 2013 at 6:59 PM, Tim Kientzle kient...@freebsd.org wrote:
On Nov 29, 2013, at 4:04 AM, Ermal Luçi e...@freebsd.org wrote:
Hello,
since SO_REUSEADDR and SO_REUSEPORT are supposed to allow two daemons to
share the same port and possibly listening ip …
These flags are
Also some discussions and improvements to it.
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html
On Fri, Nov 29, 2013 at 7:42 PM, Ermal Luçi e...@freebsd.org wrote:
Well seems Dragonfly has some version of it already from commit [1].
In FreeBSD there is the framework
And some better marketing from Dragonfly about it
http://forum.nginx.org/read.php?29,241283,241283 :)
On Fri, Nov 29, 2013 at 7:55 PM, Ermal Luçi e...@freebsd.org wrote:
Also some discussions and improvements to it.
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2013-09/msg00165.html
On Thu, Nov 28, 2013 at 7:13 AM, jb jb.1234a...@gmail.com wrote:
Luigi Rizzo rizzo at iet.unipi.it writes:
...
But I don't understand why you find ksize()/malloc_usable_size()
dangerous.
...
The original crime is commited when *usable size* (an implementation
detail)
is exported
Sure, is there a TCP version of this patch floating around? How's it
doing load balancing to multiple listeners?
-a
On 29 November 2013 11:28, Oleg Moskalenko mom040...@gmail.com wrote:
It would be nice to have this feature compiled and supported in FreeBSD
kernel by default.
Thanks
Oleg
Luigi Rizzo rizzo at iet.unipi.it writes:
...
There is a difference between applications peeking into
implementation details that should be hidden, and providing
instead limited and specific information through a well defined API.
...
Right.
If you want to improve memory management, that
On Fri, Nov 29, 2013 at 3:44 PM, jb jb.1234a...@gmail.com wrote:
Luigi Rizzo rizzo at iet.unipi.it writes:
...
There is a difference between applications peeking into
implementation details that should be hidden, and providing
instead limited and specific information through a well
The reason I wouldn't implement this is to avoid having code that
_relies_ on this behaviour in order to function or perform well.
Heck, it may not even be portable to other operating systems. Except,
Linux, I guess.
-adrian
___
Luigi Rizzo rizzo at iet.unipi.it writes:
...
If you want to improve memory management, that is, have the system (kernel
or user space) handle memory reallocation intelligently and transparently
to the user, then aim at a well defined API:
- reallocate with no copy, which means new space
On Fri, Nov 29, 2013 at 4:49 PM, Adrian Chadd adr...@freebsd.org wrote:
The reason I wouldn't implement this is to avoid having code that
_relies_ on this behaviour in order to function or perform well.
nobody ever said (or could reasonably expect to do) that.
Applications don't know if the
On Fri, Nov 29, 2013 at 5:02 PM, jb jb.1234a...@gmail.com wrote:
Luigi Rizzo rizzo at iet.unipi.it writes:
...
If you want to improve memory management, that is, have the system
(kernel
or user space) handle memory reallocation intelligently and
transparently
to the user, then aim
Quick 10.0-RELEASE status update:
- iconv(3) changes have been made in head/, and merged to stable/10
today.
- Two MFCs are undergoing review, one of which I will commit right
before updating the stable/10 branch name to reflect '-BETA4'.[1]
- Builds for 10.0-BETA4 will begin tomorrow.
What is the supposed definition of malloc_usable_size(p) in a hypothetical,
upcoming C standard? With the rest of the C standard remaining the same, one
could try:
Definition: The value of malloc_usable_size(p) is the amount of space allocated
for object p, plus the amount of space after
On Nov 29, 2013, at 3:44 PM, jb jb.1234a...@gmail.com wrote:
Luigi Rizzo rizzo at iet.unipi.it writes:
...
There is a difference between applications peeking into
implementation details that should be hidden, and providing
instead limited and specific information through a well defined
23 matches
Mail list logo
