[zeromq-dev] Questions about Coding Style

[niXman]

2012/2/12 john skaller <skaller at users.sourceforge.net>:
>
> On 12/02/2012, at 7:21 AM, niXman wrote:
>
>> The problem with dangling pointers can only be solved using its own
>> allocator.
>
> Sort of. You don't need to actually write an allocator.
> It is enough to trace all constructed sockets.

And what to do with pointers to the data for zmq_recv (), for example?

void *data = 0x3423e65;
zmq_recv(sock, data, 32, 0);

Regarding to the effeciency of malloc (): It is really very effective,
but only for memory allocation. malloc () can not prevent the
fragmentation of memory for the same reasons as the filesystem drivers
can not prevent the fragmentation of the filesystem.

For systems 24/7, the fragmentation of memory is a very big problem. I
know whereof I speak.


>
> This won't stop memory corruption of a legitimately constructed
> live socket. Neither will a custom allocator.
>
> However I take the view that malloc is already pretty good.
> I don't know if it actually is, but it is managed by people that
> care a lot about efficiency and probably already provide
> checks (on my Mac I actually get "free pointer not allocated"
> indicating some checks are being done already).
>
> If you want a fast allocator, you have to use TLS to avoid locks.
> You're allocating excess storage. If your application is using a lot
> of libraries all with their own allocators .. you're actually *causing*
> fragmentation and wasting memory.
>
> A library cannot replace "malloc", only a framework should do that.
> libgc does it, but then it's really a framework.
>
> But I'm guessing .. always worth looking at a design proposal.
>
>
> --
> john skaller
> skaller at users.sourceforge.net
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev