[zeromq-dev] Max threads (revisited)

Brian Granger ellisonbg at gmail.com
Thu Jul 8 16:46:37 CEST 2010


On Thu, Jul 8, 2010 at 7:38 AM, Pieter Hintjens <ph at imatix.com> wrote:
> 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

It seems like there are still API changes that need to be made, so I
think it makes sense to come up with an approach to versioning that
reflects that.  The only question is if there are the resources to
maintain the 2.0.x series and develop the new 2.1.x series.

> 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?

Because 0MQ is still a moving target (I am fine with  this as long as
the versioning scheme is clear), I plan on maintaining separate 2.0
and 2.1 series for pyzmq.  But, I will say that right now the biggest
thing we are dealing with is all the bugs in 2.0.7.  Thus, I will
probably follow whatever branch the bug fixes go into.  If bug fixes
are not back ported to 2.0.7, then I will quickly abandon it.

What I would really like to see is a solid test suite that is run
daily on all platforms so that we can quickly detect regressions.  The
Python bindings are solid enough now that we could use the Python test
suite for this purpose.  It makes writing tests easy and quick.

Summary:  I don't care about API changes as much as I care about bug
fixes currently.

Cheers,

Brian




> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list