[zeromq-dev] Application design. Overcomplicated?
Ilja Golshtein
ilejncs at narod.ru
Mon Apr 18 10:56:16 CEST 2011
Pieter,
sorry for carelessness - I expected to see zctx_new somewhere in internals but now I can see the idea is
to explicitly call it at application level.
Everything fell into place.
libzapi looks very good, though we are C++ shop.
In my company we've created number of things like reactor layer and multipart processing.
Do hope to make them as clean as libzapi and open sources.
Thank you for your kind explanation.
18.04.2011, 12:35, "Pieter Hintjens" <ph at imatix.com>:
> 2011/4/18 Ilja Golshtein <ilejncs at yandex.ru>;:
>
>> There is zlist_push call in zctx__socket_new without any mutex or something. The consideration is if it is safe to call zsocket_new from different threads as we can see in server_worker method in asyncsrv.c. My feeling is these threads use the same zctx_t. Is it wrong?
>
> Each thread has a separate zctx_t object, each with its own list of
> open sockets. The various zctx_t objects may share the same underlying
> 0MQ context, if they're created as attached threads. This lets libzapi
> safely shutdown automatically. The one thing that's not possible is
> socket migration, though it could be added.
>
>> In zthread.c zctx_thread_new method is mentioned, though I failed to find it. Is it renamed?
>
> Yes, I moved the thread functions into their own zthread class, and
> the methods are zthread_new (detached thread that doesn't share an
> underlying 0MQ context) and zthread_fork (attached thread that shares
> the same 0MQ context).
>
>> What is there behind server_task and client_task termination? Is client_task and server_task epilogue epilogue with zctx_destroy really meaningful having in mind infinite loop above?
>
> When using detached threads (which simulate separate processes, but
> using threads) it's kind of meaningless to try to get clean process
> shutdown. It doesn't make sense architecturally. In the examples I've
> ensured attached threads always end cleanly, but detached threads
> don't.
>
>> What is your attitude towards libzapi in C++?
>
> I'm hoping the new C++ binding (libzapi++?) will adopt some of the
> same semantics, maybe reuse some of the code. Obviously there are
> parts that aren't needed, e.g. list and hash containers. Other parts
> seem worth reusing. I've started a wiki page to collect abstractions
> which we could try to get spread across all language bindings:
>
> http://www.zeromq.org/topics:binding-abstractions
>
>> My zapi version is 2c1bd38bfd1220226c04c03a39a28e62adf4c631
>
> I'd suggest taking the latest master, there are a few issues I fixed
> while hammering libzapi in some of the examples.
>
> When I have reports of other people using it and not finding problems,
> I'll make a stable release.
>
> Cheers
> -Pieter
--
Best regards,
Ilja Golshtein.
More information about the zeromq-dev
mailing list