Hi Alan, I've been playing with the reactor a bit, and one of my early thoughts was: how do you scale this thing across multiple cores?
The architecture I've worked with before uses (approximately) one selector + thread pair per core and balances connections across the selectors. Anything non-blocking is done on the selector/thread pair (to avoid context switches and maintain a small working set for each thread). Anything with the potential to block gets dispatched into a thread pool. I /think/ the way you would use the reactor for this kind of architecture is to have one reactor + thread pair per core. That said, I've not tested this hypothesis. If the architecture that you're thinking of always dispatches "ready" file descriptors into a pool of threads - then I'm _not_ sure that this is something that the reactor (as it currently stands) can easily be slotted into. Regards - Adrian -----Alan Conway <acon...@redhat.com> wrote: ----- >To: proton@qpid.apache.org >From: Alan Conway <acon...@redhat.com> >Date: 04/30/2015 07:47PM >Subject: Question about pn_reactor and threads. > >Can the proton reactor be used to deliver work from multiple connections to a >thread pool, where >work from a given connection is only handled by one thread at a time (so >access to each >pn_transport and it's stuff is serialized)? That is a pretty standard model >for servers. It >doesn't look to me like this is the case but I may be missing something. If it >is the case, what's >the pattern for doing it? Cheers, Alan. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
