[zeromq-dev] Client API with zactor

Kevin Wang kevin at spikegadgets.com
Sat Jan 20 00:06:10 CET 2018

The intended product is for labs to write their own modules and scripts, 
but also communicate with our provided software. We'd like to hide the 
networking details away from them.

Thanks for the suggestions Michal and Osiris, I'll look into those.

I think I will have to pass messages back to the client in the end, to 
be on the safe side.


On 01/19/2018 02:41 PM, Michal Vyskocil wrote:
> Hi,
> The main question is why do you abstract away czmq and sockets? What 
> problem do you want to solve?
> Anyway an example of abstraction over zeromq sockets is mlm_client_t 
> from zeromq malamute project. Each client has own actor communicating 
> with server and msgpipe inproc socket used to communicate between 
> actor and client thread.
> Btw: you're right that it's better to pass messages to client rather 
> than execute callbacks from main thread inside actor thread.
> Michal
> Dne 19. 1. 2018 9:52 odpoledne napsal uživatel "Kevin Wang" 
> <kevin at spikegadgets.com <mailto:kevin at spikegadgets.com>>:
>     Hello everyone,
>     I am building a client API that abstracts away sockets and the
>     Zeromq and CZMQ layer. To do that, my class has a zactor
>     containing a zloop, polling on all the various sockets in the class.
>     I eventually want my users to define their own "events", which are
>     messages containing an event name (string) and associated data in
>     the next frame, and for them to write their own functions that are
>     called by the zloop when their messages arrive. I am doing this by
>     creating a virtual function for them to override, which they can
>     use to define their own behavior.
>     And everything was good, until I realized that their defined
>     function would be called in the zactor thread, not the user's
>     thread. If they chose to define their function to change some
>     variable or call some other function, that would cause a race
>     condition.
>     At least, that is what I think could happen. I realize that this
>     is only loosely related to zeromq, and more about API design, but
>     is there anyone else that has run into this problem? Is this a
>     valid concern?
>     My proposed solution would be to push these event messages to the
>     user thread, and make the user call a processEvents() function
>     when they can, which pulls the event messages and acts on them.
>     Similar to:
>     while(!quitCondition){
>     client.processEvents()
>     //Run other code
>     }
>     I am new to dealing with threads and am not sure if this is a
>     common pattern, or if there is something basic I am missing.
>     Thanks
>     Kevin
>     _______________________________________________
>     zeromq-dev mailing list
>     zeromq-dev at lists.zeromq.org <mailto:zeromq-dev at lists.zeromq.org>
>     https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>     <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180119/a79b0857/attachment.htm>

More information about the zeromq-dev mailing list