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

MrMstormo . mstormo at gmail.com
Thu May 12 04:50:38 CEST 2016


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
>>                      -> | ->        ->
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160511/fc434dc7/attachment.htm>


More information about the zeromq-dev mailing list