[zeromq-dev] question about czmq zctx_destroy

Evan Gates evan.gates at gmail.com
Thu Apr 18 17:17:58 CEST 2013


Out of curiosity, why don't calls that take ownership also nullify a
reference? For example, after a zmsg_push() the message owns the frame and
will destroy it when the message is destroyed (zmsg_destroy(),
zmsg_send()). Why doesn't this nullify the frame reference? (I personally
just end up doing it myself the next line as it makes cleanup in case of
errors easier for me.)

-Evan


On Thu, Apr 18, 2013 at 8:03 AM, Michel Pelletier <
pelletier.michel at gmail.com> wrote:

> Ok, that makes perfect sense now, destroy is overwriting my pointer with
> NULL so that I can check that.  I'm using the picolisp "native" function
> which is working well for all other czmq functions.  It's not a problem
> anymore, I'm faking it by wrapping my pointer in a one item structure and
> passing a pointer to that.  Almost have complete bindings!
>
> -Michel
>
>
> On Wed, Apr 17, 2013 at 10:40 PM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> On Thu, Apr 18, 2013 at 7:17 AM, Michel Pelletier
>> <pelletier.michel at gmail.com> wrote:
>>
>> > This is nagging me in a minor way:
>> >
>> > CZMQ_EXPORT zctx_t *
>> >     zctx_new (void);
>> >
>> > //  Destroy context and all sockets in it, replaces zmq_term
>> > CZMQ_EXPORT void
>> >     zctx_destroy (zctx_t **self_p);
>> >
>> >
>> > Why does new return a pointer to a context, but destroy wants a pointer
>> to
>> > that pointer?  I'm trying to call this functions via an FFI interface,
>> but I
>> > can't pass the result of new to destroy and I don't have the equivalent
>> of
>> > the & operator in the FFI environment.
>>
>> Hmm... the "destroy nullifies reference" pattern is one we've been
>> using for sometime in C with success. I'd not realized it might create
>> problems for bindings.
>>
>> > I've got a workaround, but is there a particular reason for this?
>>
>> The reason for the style is to clean up after destruction so that
>> further code can catch null references and either ignore them or
>> assert, but not try to access freed memory. That does work pretty
>> well. All the CZMQ modules work like this.
>>
>> What are the limitations you have in FFI?
>>
>> -Pieter
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130418/aa36ad37/attachment.htm>


More information about the zeromq-dev mailing list