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

[Doron Somech]

You can try and use zeromq thread safe sockets, which are the client,
server, dish, radio, gather and scatter.

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

> It is a thread pool, however, the driver might be servicing more than one
> client, and as such the thread pool it designed to grow and shrink on
> demand. As such, the map may grow "indefinitely" when threads die (imagine
> a pulsating thread pool) and my application never sees it again.
>
> I guess I could cycle Least Recently Used sockets to a new thread when my
> "socket pool" is maxed out.. Hmmm
> But then again, wouldn't a map lookup be slower than a Futex/Critical
> Section/Spinlock-protected message send in the end?
>
> (Btw, I didn't mention it initially, but this is a system for both Linux
> and Windows. Different kernel drivers, but same behavior. So cannot rely on
> Unix message queues, f.ex.)
>
> --
> .marius
>
> On Wed, May 11, 2016 at 8:23 PM, Jim Idle <jimi at temporal-wave.com> wrote:
>
>> 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
>>>                      -> | ->        ->
>>>
>>>
>
> _______________________________________________
> 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/20160514/542d2675/attachment.htm>