[zeromq-dev] Multiple (cycling) threads to single PUB

Jim Idle jimi at temporal-wave.com
Thu May 12 03:23:40 CEST 2016


Is there some reason that you could not use pthread_self() as an index into
a map? The map contains the PUB socket for that thread (you said it is a
thread pool so it is finite), which if not present is then created. This
would give one PUB for one thread.

Or you could not use PUB at that point but use something like Unix message
queues.

Jim

On Thu, May 12, 2016 at 3:20 AM, MrMstormo . <mstormo at gmail.com> wrote:

> Hi,
>
> I understand that the normal paradigm for multiple threads communication
> is to have a separate socket for each thread, and connect those to a single
> forwarder. However, I have a special situation where I could need some
> input/ideas on most optimal setup.
>
> I have a user-land application which gets callback from a kernel driver,
> which may do the callbacks in multiple threads (think multi-threaded FUSE,
> for example).
> Now, I would like for my application to provide debug info regarding the
> callbacks through a PUB socket to a controlling client application, so
> ideally I would then create a unique socket for each worker thread, and
> forward it. However, I cannot guarantee that the worker threads stay the
> same. The mechanism for the worker threads maintains a pool of worker
> threads, but depending on other services, the threads in the pool may be
> rotated, as well as terminated and created between calls.
>
> It seems to me the only way I can handle it then would be to just have a
> single PUB socket, and have each worker lock while they send a message on
> the socket. Any suggestions?
>
>       Kernel Land       | User Land
> ------------------------------------------------------------------
>                      -> | ->        ->
> IO request -> Driver -> | -> Driver -> Service[PUB] -> [SUB]Client
>                      -> | ->        ->
>
> --
> .marius
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160512/bdebd347/attachment.htm>


More information about the zeromq-dev mailing list