[zeromq-dev] queue limits

[Martin Sustrik]

Hi Pavel,

Your patch is commited to zeromq1 (revision afda900).

Thanks!
Martin

Pavel Gushcha wrote:
> Yes, i submit it under MIT license.
> 
> 2009/10/20 Martin Sustrik <sustrik at fastmq.com <mailto:sustrik at fastmq.com>>
> 
>     Hi Pavel,
> 
>     Thanks for posting the patch. Are you OK with submitting it under
>     MIT license?
> 
>     Martin
> 
>     Pavel Gushcha wrote:
> 
>         Martin, please review my patch, may you will have some
>         suggestions. I added set_watermarks() to api_thread_t and
>         engine_base_t.
>         first i thinked add them to i_engine, but this is abstract
>         interface and doesn't contain any data member. This patch works
>         for me, test programs i attached too.
> 
>         bp_hwm and bp_lwm custom values flow path:
>         api_thread_t::set_watermarks->dispatcher_t::(get/create)->engine_factory_t::(create_engine/create_listener)->engine_base_t::set_watermarks
> 
>         listener objects pass custom values of bp_hwm and bp_lwm to
>         created engines by calling their set_watermarks() method.
> 
>         if all is ok, please commit patch to master branch
> 
>         2009/9/29 Pavel Gushcha <pavimus at gmail.com
>         <mailto:pavimus at gmail.com> <mailto:pavimus at gmail.com
>         <mailto:pavimus at gmail.com>>>
> 
> 
>            Agree, this is better solution! powerful and simple, as it
>         must be :-)
> 
>            2009/9/29 Martin Sustrik <sustrik at fastmq.com
>         <mailto:sustrik at fastmq.com>
>            <mailto:sustrik at fastmq.com <mailto:sustrik at fastmq.com>>>
> 
> 
> 
>                    I forgot about bindings :-) You are right, adding
>                    set_watermarks() will be simpler. I'll syncromize
>         calls to
>                    create_queue/create_exchange/bind by global mutex.
>         There is
>                    no performance penalty, because in common usecase all
>                    objects/bindings are created only at application start.
> 
> 
>                Goodo. Alternatively, you can make the new function member of
>                app_thread_t - that one is used from a single thread so
>         you'll
>                do without synchronisation altogether.
> 
>                Martin
> 
> 
> 
> 
>