[zeromq-dev] feedback on proposed Context API addition

[john skaller]

On 10/02/2012, at 1:19 AM, Chuck Remes wrote:
> 
>> Also, since this API would exclude thread_safety as it too is an additional context
>> construction option, it may be right to start thinking about
>> 
>> 	zmq_setcontextopt
>> 
>> function that looks like
>> 
>> 	zmq_setsokopt
> 
> I'm not so sure about this. The context object is setup immediately upon a call to zmq_init(). Creating a separate set of calls to twiddle options on it implies that the context would a) have to restart itself under some circumstances, or 2) delay initialization until a specific call to yet another new api method (zmq_ctx_build()) were called to complete its initialization.

Good point. The thread-safety thing would work fine, since it only applies to subsequent
calls. The CPU affinity thing is more fundamental.

> 
> Yuck again. This is where a C++ interface with overloading would come in handy.

Yes, and defaults. There is a better way, in high level languages it's trivial,
in C++ it would work too, but in C .. well .. you'd use an array.

You use a list of options. One could do this with sockopts: instead of setting 
a single opt at a time, set a whole list of them.

The advantage is clear for zmq_init; all the options get processed first,
before starting up threads, etc.

BTW: not actually proposing this. In C, it would require a whole swag of
functions to manage lists. In C++ you'd need to make a minimally lame
representation the options (C++ lacks a proper variant type).


>> Not directly, my modification to the style guide prohibits this. You'd do it with
>> an inner function all the public interfaces called. Same effect though.
> 
> Yes. I have built a bunch of my Ruby binding code to follow this same pattern, so I agree the same concept should apply to the C API.

Yeah, it would be vital in a binding. I don't know Ruby but in Python certainly
the ref-counting protocol requires very careful management in bindings.

In such cases the "dont call public members" rule is even more vital because
of the much stronger invariants implied by type mapping across language
boundaries.

> It's a little refactoring from what we have today but even I could do it with my weak-ass C skills.

:-)


--
john skaller
skaller at users.sourceforge.net