[zeromq-dev] czmq and zalloc - handling OOM situations

AJ Lewis aj.lewis at quantum.com
Mon Sep 12 17:20:46 CEST 2011


On Mon, Sep 12, 2011 at 09:32:02AM -0500, Pieter Hintjens wrote:
> On Mon, Sep 12, 2011 at 9:09 AM, AJ Lewis <AJ.Lewis at quantum.com>
> wrote:
> 
> > I'm just starting to use zmq and czmq.  After poking a bit at the
> > APIs and the czmq code, I'm a bit confused about the zmalloc macro
> > and associated safe_malloc() wrapper.  It appears that the
> > assumption in czmq is that cmalloc never fails, which is generally
> > true in Linux, but not necessarily true on other OSes.  Is there a
> > reason czmq doesn't propogate a malloc error back up through the
> > call stack, and instead just abort()s?  I could #define
> > _ZMALLOC_DEBUG, but then functions like zframe_new() would just
> > segfault in the OOM case.
> 
> We could propagate the error, sure. The current approach is the
> simplest one that plausibly works. I've no preference either way,
> except that changes to CZMQ be driven by demand.
> 
> Do you want to try patching the code to make it propagate malloc
> errors? Or would you like me to look at this?

I could put together something - I'm afraid it will break the current
API though, as void functions that call zmalloc (or call other functions
that call zmalloc) should propagate the error...is that acceptable?

> Note that the zmalloc macro also initalizes (zeroes) memory.

Right - that makes sense.

Thank you,
-- 
AJ Lewis

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.



More information about the zeromq-dev mailing list