[nanomsg] Re: Nanomsg List Alive?

  • From: SGSeven Algebraf <a1rex2003@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Fri, 10 Feb 2017 19:49:36 -0500

Hi All,
I am sure that I do not understand the design. Why do we need need a two
threads per socket? Why not to have just one thread for ALL writers and
just one thread for ALL readers? Obviously, the multiplexing between
sockets would have to be solved withing one thread to make this approach
viable.
I understand that threads give a physical separation for the sockets and
the sockets in those threads can receive/transmit forever without any need
for intervention. But there is a penalty for this convenience. (ATM, I am
in a process of porting relatively big applications from QNX to Linux and
after some consideration I have decided not to use threads at all).
Thanks,
Samuel

On Fri, Feb 10, 2017 at 6:35 PM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:

I was actually using two threads (a reader and a writer) per socket.  Two
thousand threads worked. But I also had other threads and basically
discovered that I was grossly limited by their scalability even with tiny
thread stacks.  Conversely on Solaris I have used the same architecture
with kernel threads handling over 10000 connections without breaking a
sweat (over 20k threads).  RAM consumption was very modest.

Threads on other systems suck.  There is a hard limit of 2048 threads per
process on MacOS and on Windows things fell apart at about 2k threads.
Unacceptable.

Sent from my iPhone

On Feb 10, 2017, at 2:47 PM, Matthew Hall <mhall@xxxxxxxxxxxxxxx> wrote:

On Tue, Feb 07, 2017 at 12:51:27PM -0800, Garrett D'Amore wrote:
falling over around only 2K threads

It would help to see a bit more specifics what went wrong for you here.

Generally you can do 10K or 20K moderately active sockets on one epoll or
kqueue.

Not to mention multiple thousand processes or threads (internally they're
really the same) in Linux NPTL w/ O(1) scheduler according to IBM's
benchmarking after those were added to the kernel.

This sort of performance could almost surely not be replicated outside of
Linux, BSD, or Solaris however.

If however you're making entire threads for single sockets, or trying to
pass
the sockets between threads, that will work very badly. Particularly
with UDP
sockets, which sadly still don't have good ways of making associativity
between different connections through the same socket descriptor.

Matthew.



Other related posts: