[zeromq-dev] Cleaning-up context creation API

[john skaller]

On 16/02/2012, at 12:16 PM, Pieter Hintjens wrote:

> On Wed, Feb 15, 2012 at 6:07 PM, john skaller
> <skaller at users.sourceforge.net> wrote:
> 
>> which is a bit risky IMHO. The reason is: you're delaying error detection
>> in the launching of the threads. That makes it impossible to return
>> an error code.
> 
> True. However errors can be returned after the fact; it's the same
> issue with zmq_connect.

True, but now you have no idea what the source of the error is.
Was it the socket creation call or the context initialisation?
Worse .. if we delay socket creation too ..  we do a send ..

was it the send, the socket creation, or the context creation?

Errors like EAGAIN mean "THIS function should be tried again later"
and now we don't know which one.

The only way around this that makes any sense is to add new errors like:

ECTX_CANT_MAKE_ALL_THOSE_THREADS

so if recv gets the error at least we know what the error is.

> At least a sane naming hierarchy so that people don't have to remember
> lots of different naming schemes. The current API is really
> inconsistent in many ways and that makes it harder to learn than it
> needs to be.

Of course I have no objection to that.

>> So if we're going for consistency .. "init" sucks. zmq_ctx_init creates
>> a ctx. but zmq_msg_init doesn't, it initialises an existing one.
> 
> Yes, this has been pointed out before :-) We can continue to improve
> things but one step at a time, and keeping old names alive.

It isn't worth a minor name change with deprecation and the works,
only to leave  other minor inconsistencies floating around.
Might as well rethink the whole scheme .. obviously without making
gratuitous changes. 

It may not be just the names that change: the form of arguments
might change too, and that's something best not done very often.

I'm sure you agree :) 

> All welcome but it has to be done carefully, and without breaking things.

A completely new API can't break anything.

>> Actually I think message should be heap allocated like everything else.
>> In a well written program, you can still move the buffers around so
>> you don't need a fresh message container thing for every
>> new blob of data. [** Felix binding does that anyhow, it's just
>> easier for the clients and malloc is fast]
> 
> Not possible if you want performance (small messages must be stack allocated).

You're missing the point here I think. The message BUFFERS can be
stack allocated. The message objects can be heap allocated because
you only need a few of them in any program.

>> I guess in summary: if you're going to make a new C API, and deprecate the old
>> one, we might as well re-examine the whole structure.
> 
> That is exceedingly dangerous for several reasons. First, you scare
> people who depend on, have learned, the old API. Second, you will
> enter endless discussions over rather minor details (bike shedding,
> peek vs. getopt style). Lastly, you will break or at least force work
> on dozens of language bindings.

I concede points one and two but not three: examination doesn't
imply any change, just thinking about it :)

> But my advice is also to _absolutely_ not aim for large, disruptive
> changes. One thing at a time.

Ok, fair 'nuf.

But you have to concede in turn that lazy evaluation and the implications
for error handling are major changes. It may look small visually but the semantic
implications are profound.

--
john skaller
skaller at users.sourceforge.net