Hi all, See https://github.com/zeromq/czmq/issues/459
I'm considering making some breaking changes to CZMQ and would like to get consensus on whether this is worth doing or not. ## Background The background is a new zsock class for wrapping sockets. Maarten Ditzel and myself have pushed an initial implementation of that, to bring sockets into line with other objects. Mainly, they get a proper construct/destruct API. I've made zmsg, zstr, zframe, zloop, and zpoller with with both low-level libzmq socket handles (void *) and zsock_t instances, using some simple runtime probing. Thus, both these are valid: void *handle = zsocket_new (ctx, ZMQ_PUB); zsocket_connect (handle, "tcp://127.0.0.1:9999"); zstr_send (handle, "Hello"); and void *sock = zsock_new (ZMQ_PUB); zsock_connect (sock, "tcp://127.0.0.1:9999"); zstr_send (sock, "Hello"); Unlike the current zctx/zsocket API, callers would have to explicitly destroy any zsock instances, exactly as for any other class. It's a little more work, but I think less surprising than what we have today. ## Simplification We can remove contexts from the API I think. I've started in zsock_new(), which has no ctx argument. Here's my plan: 1. zsock_new () uses a global context for the main thread, and destroys this context automatically at process exit. 2. zsock_new () would use a thread-local context in detached threads, to be destroyed when the thread ends. 3. zsock_new () uses the global context in attached threads. This has no impact on existing applications, which can continue to use zctx/zsocket. ## Threading model Though the attached/detached thread model has worked very well, I think we can redesign it to be simpler and cleaner: * Proper constructor and destructor (using pthread_join) for threads * Remove ctx from thread function API * Simpler implementation as we don't have to shadow contexts, etc. Continuing to formalize our threading model, I'd like to use the term "actor" and thus create a new zactor class. The non-portable code can move into zsys where it belongs. ## Deprecated classes This means we deprecate zctx, zsocket, zsockopt, and zthread, and introduce zsock and zactor for new applications. ## Breaking changes Now the damage: the constructors for zauth, zbeacon, zmonitor, and zproxy all take a zctx argument. I'd like to remove this argument. That will break existing applications. We have a few options: 1. Simply change the constructors, and force applications to upgrade. This would break the ABI. 2. Provide both old and new constructors, using a new naming scheme for the new constructors. This is the proper way to do it, but it would create inconsistency. 3. Allow the library to provide old or new depending on build-time macro in libczmq. 4. Allow the caller to access old or new depending on caller-compile time macro. My preference would be 1 and then 4. Comments? -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
