On Mar 1, 2010, at 9:29 PM, Brian Granger wrote:
> Chris,
>
>> 2. I prefer option 2.
>>
>> ctxt = ZMQ::Context.new
>> sock = ctxt.socket(ZMQ::PUB)
>
> Other than the socket being named "create_socket" this is what I am
> doing with Python bindings.
>
Different style in naming. I prefer to keep it more Rubyist. If create_socket
is common in Python, it's perfectly good that way.
>> This style allow chaining... especially for one-liner.
>>
>> ZMQ::Context.new(1,1).socket(ZMQ::SUB).connect("udp://eth0:224:0.0.1:5555")...
>> blah blah blah
>
> Hmm, in Python, this usage would not hold references to the socket and
> context objects which would trigger the automatic cleanup code. If
> you don't have automatic cleanup code, you have just lost refs and
> won't be able to call the cleanup code manually. Hmm....can you
> elaborate ...
>
>> I'm developing a Ruby wrapper on top of rbzmq for more convenient usage in
>> Ruby. When it's in a usable state, I'll post it here.
>
> That 0MQ API is already pretty minimal and simple, so I am not sure
> how it could be made more convenient. What type of things are you
> thinking of? I might want to include some of them in the python
> bindings.
>
I'd avoid repeating myself later. Look for an email in a couple days from me
on my Ruby library. I'd include a couple examples to demonstrate both.
>> 3. Ruby, like any GC based languages, needs explicit close/term/disconnect
>> methods for cleaning up resources used. Even for C++, I'd argue that it's
>> better to avoid relying on destructor 100% for implicit resource cleanup.
>> It's especially true in Java, the finalizer is not guaranteed to be called
>> upon process termination AFAIK and it's unpredictable when it'd get called.
>> (Not saying that Java's finalizer is the same as C++ destructor.)
>
> But in a situation like 0MQ, it seems like the greater danger is to
> not perform the cleanup by forgetting to call the cleanup method.
> Thoughts?
>
It doesn't hurt to have the cleanup code in the destructor *also*, but it
shouldn't be the only place IMO. One may choose to manage the lifetime of the
"socket" resource explicitly in C++.
Chris
> Cheers,
>
> Brian
>
>
>> Chris
>>
>> On Mar 1, 2010, at 12:17 PM, Martin Sustrik wrote:
>>
>>> Hi Chuck,
>>>
>>>> For the Java and Ruby cases, why not move to a factory pattern where
>>>> a class method instantiates and returns an object containing the
>>>> context and all of the other bits?
>>>>
>>>> // Java z = ZMQ.factory(); s = z.makeSocket(ZMQ::PUB);
>>>>
>>>> # Ruby z = ZMQ.factory s = z.make_socket ZMQ::PUB
>>>>
>>>> This way there isn't any confusion about instantiating what looks
>>>> like a namespace.
>>>
>>> Yes. That's the same thing. It just renames context to factory.
>>>
>>> The other piece here is using a different syntax for creating sockets
>>> (issue pointed out originally by Brian Granger):
>>>
>>> s = z.makeSocket (ZMQ::PUB);
>>>
>>> vs.
>>>
>>> s = ZMQ::Socket.new(z, ZMQ::REP);
>>>
>>> So far it seems that people prefer the former.
>>>
>>>> I must say I prefer the hiding the context away. Whenever I am made
>>>> to pass the same parameter around I usually write a wrapper class for
>>>> it anyway just to handle it for me.
>>>
>>> Right. The problem is that context cannot be completely hidden. The
>>> reason why it exists at all is that several instances of 0MQ may get
>>> into the same process - think of linking your app with two libraries,
>>> each using 0MQ. Having a single global context would make the libraries
>>> interfere in unexpected ways.
>>>
>>> Martin
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> [email protected]
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> [email protected]
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
>
> --
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> [email protected]
> [email protected]
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
