[zeromq-dev] Proposal for 2.0.7: Cleaning up the ZMQ_* constants
sustrik at 250bpm.com
Fri Apr 16 08:42:44 CEST 2010
Dhammika Pathirana wrote:
>> with the introduction of more send/recv flags (ZMQ_SNDMORE), socket options
>> (ZMQ_RCVMORE) and the experimental device api (ZMQ_STREAMER et al) the ZMQ_
>> namespace for constants is starting to look rather ad-hoc and crowded.
>> There are two main motivations for doing the cleanup. Firstly, crowding
>> everything under ZMQ_ leads to less room for future expansion. Secondly,
>> it's nicer from the programmers point of view to be able to identify what
>> area of the API a ZMQ_XXX constant is relevant to.
> Why not define these as enums?
> Then the API is much cleaner and we don't need to lookup man pages.
0MQ API tries to mimic Berkeley sockets API thus defines rather than enums.
>> In the interest of cleaning things up now rather than later
>> I'd like to get some discussion on this started. What follows is a draft
>> Infrastructure flags:
>> ZMQ_POLL should become ZMQ_CTX_POLL, since it is specific to zmq_init()
I thought of dropping this flag completely and allowing poll by default.
Doing so would add ~2us to the latency though.
>> Socket types:
>> Either leave them as they are now, since they are the basic building block
>> of 0MQ, or optionally rename them to ZMQ_SOCK_XXX, so e.g. ZMQ_REQ becomes
>> Socket options:
>> This is the biggest group and also the most ad-hoc.
>> Options which are applicable to all sockets ("core options") should be
>> renamed ZMQ_SO_XXX. Options applicable to only certain specific transports
>> should be renamed to ZMQ_TRANSPORT_XXX. This would give us the following:
>> Core options:
>> ZMQ_HWM == ZMQ_SO_HWM
>> ZMQ_LWM == ZMQ_SO_LWM
>> ZMQ_SWAP == ZMQ_SO_SWAP
>> ZMQ_AFFINITY == ZMQ_SO_AFFINITY
>> ZMQ_IDENTITY == ZMQ_SO_IDENTITY
>> ZMQ_SNDBUF == ZMQ_SO_SNDBUF
>> ZMQ_RCVBUF == ZMQ_SO_RCVBUF
>> Specific to PGM:
>> ZMQ_RATE == ZMQ_PGM_RATE
>> ZMQ_RECOVERY_IVL == ZMQ_PGM_RECOVERY_IVL
>> ZMQ_MCAST_LOOP == ZMQ_PGM_MCAST_LOOP
>> ZMQ_SUBSCRIBE/ZMQ_UNSUBSCRIBE -- these are specific to ZMQ_SUB sockets
>> only. I'm not sure how that could be reflected in their naming. Maybe
>> just ZMQ_SUB_ADD, ZMQ_SUB_REMOVE?
>> ZMQ_RCVMORE in that it is related to zmq_recv() would seem nicer as
>> ZMQ_RECV_MORE. ZMQ_SO_MORE might also work.
>> Send/recv flags:
>> ZMQ_NOBLOCK -- stays as it is?
>> ZMQ_SNDMORE -- as for ZMQ_RCVMORE, I'd prefer ZMQ_SEND_MORE.
>> Another option with the above if we want to be really consistent is
>> defining ZMQ_SR as a prefix for send/receive flags, which would give us
>> ZMQ_SR_NOBLOCK, ZMQ_SR_MORE.
As for socket options it should be noted that BSD sockets define the
constants according to the layer they are used at (consider SO_LINGER
Following this logic 0MQ-specific socket options would be simply
prefixed by ZMQ_.
There are several exceptions though: PGM_RATE and PGM_RECOVERY_IVL at
the moment. If possible we should mimic option names as used in RFC3208.
ZMQ_SNDBUF, ZMQ_RCVBUF => SO_SNDBUF, SO_RCVBUF.
It's not obvious how to prevent collisions between 0mq-defined and
OS-defined constants in such a case.
More information about the zeromq-dev