[zeromq-dev] Memory allocation/Exception

[Martin Sustrik]

Ayman,

> we are planing to use ZeroMQ since our performance tests runs fine so 
> far, but we noticed that you allocate
> 
> memory using 'new' and then make assert check, which will not be 
> evaluated in case of std::bad_alloc.

Good point. 0MQ is deliberately not using exceptions as it both boats 
the code and impacts performance. The issue is quite complex though as 
not all STL implementations allow disabling exceptions etc.

Anyway, you are right, all news should be replaced by new(nothrow). It's 
still to be investigated how well do proprietary compilers on exotic 
platforms handle the nothrow syntax.

> <example>
> 
> libzmq ver0.5: dispatcher.cpp
> 
> lines: 34/35
> 
> pipes = new command_pipe_t [thread_count * thread_count];
> 
> assert (pipes); // will not be arrived in case of std::bad_alloc
> 
> </example>
> 
>  
> 
> Since I don't see in your code that you overwrite the new operator, so 
> modern compiler will throw std::bad_alloc
> 
>  
> 
> <C++ISO_standard>
> 
> 3.7.3 Dynamic storage duration
> 
> ========================
> 
> The following allocation and deallocation functions
> 
> (18.4) are implicitly declared in global scope in each translation unit 
> of a program
> 
>  
> 
> void* operator new(std::size_t) throw(std::bad_alloc);
> 
> void* operator new[](std::size_t) throw(std::bad_alloc);
> 
> void operator delete(void*) throw();
> 
> void operator delete[](void*) throw();
> 
> </C++ISO_standard>
> 
>  
> 
> Even if the compiler does not throw bad_alloc and initialize the pointer 
> with NULL, in This case I would expect to
> 
> do something else (e.g. set another error handler function for such 
> failure) than crashing the whole application.
> 
> Because the user of your API may want to wait until the system have 
> enough memory and retry again.
> 
>  
> 
> I just want to understand why you have selected the assertion way?

Because there's very little you can do when computer is already out of 
resources. Even simplest attempts to fix the problem tend to fail in 
that case. The goal is never to let such a thing happen. That's why 
we've introduced queue limits and (with version 0.6) on-disk offload of 
the queues that allows you to store gigabytes of data without affecting 
memory footprint etc.

Martin