[zeromq-dev] Max threads (revisited)

[Pieter Hintjens]

On Thu, Jul 8, 2010 at 3:59 PM, Martin Sustrik <sustrik at 250bpm.com> 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