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 . <[email protected]> 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 <[email protected]> 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 . <[email protected]> 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
