On Thu, Jul 8, 2010 at 3:59 PM, Martin Sustrik <[email protected]> wrote:
>> Even if modifying the context on the fly is difficult, > > Yes, it is. It would break the lock-free algorithms. Applications can do an internal restart (create new context, recreate all sockets) if they for some reason need to increase the number of threads. it is still much better than requiring a code change / recompile. >> It should be >> configurable IMO just as sockets are, before first use. > > That would mean yet one more API change. It's up to you to decide on > API/ABI stability policy so that users experience as little pain as > possible. It would have been nice to remove the IO threads option during the last change but what's done is done. Here is the stability policy I'd suggest: * The version numbering needs review so that 2.0 is stable and 2.1 starts a new unstable branch * In this branch (2.0.x) there should be no breakage of the API but we can add new aspects and we can deprecate old ones * A new unstable 2.1 can introduce API changes So for example we IMO do this in 2.0 stable: * Add get/setcontextopt methods * Use these to set number of IO threads (default 1) and number of process threads (default 50) before first use of context * Leave the IO threads argument to context creation but make it have no effect And in 2.1 unstable: * Remove the IO threads argument completely This approach lets us continue to improve the API in both stable and unstable branches. The downside is that language bindings will need to choose which branch they build with. In effect it means that language bindings also need a stable / unstable branch. Thoughts from others? -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
