[noPoll] noPoll : Query related to I/O mechanism, max concurrent connections.

Francis Brosnan Blazquez francis en aspl.es
Jue Dic 26 14:45:41 CET 2013

> Hello Francis,

Hi there,

Sorry for the delay, been busy ;-)

> Thanks a lot for this info. I was also of the impression that noPoll
> provides it internal select,poll and epoll I/O based on some switch.

That's right..

> But traversing the code I found out that only 'select' is implemented
> as part of default. Does that mean we need to write our own waiting
> mechanism in case we wish to use 'NOPOLL_IO_ENGINE_EPOLL' etc, and
> also need to change e.g. 'nopoll_io_get_engine' as it didn't use
> 'engine_type' currently.

Ok, several things here. 

You could go and update noPoll to add support for epoll but, if you
already have a I/O waiting mechanism or you are planning you have one,
do not update noPoll and put your all efforts into your I/O waiting
mechnism (using epoll). 

This way you'll have an independent I/O waiting mechanism that will play
well with all next noPoll releases (because you are using its API). 

Once you have your own I/O waiting mechanism, you take a look at the
following link to have each noPoll socket watched:


> So my understanding is that in case we wish to use internal noPoll
> I/O, we need to write wrappers and waiting mechanism (would need to
> change library functions as well), and in case we need to integrate to
> our existing I/O, we need to go as you have described.

Ok, to this particular matter, you only have one waiting I/O in your
app. It could be noPoll's or yours but not both at the same time (excuse
me if I got it wrong from your words). 

Because that, I recommend you to have your own I/O waiting poll
mechanism (plus all the features you may want to add it)...so you can
use it to wait and watch noPoll sockets...plus the fact that it will
allow you easy upgrades when noPoll releases come out.

> When I tried to test concurrent connections using my client with
> noPoll, I could not proceed more than 1050 connections (I guess the
> limit due to default 'select' and my kernel limitation for the same).

Ok, that's because you have to update FD_SETSIZE to a bigger value at 
compilation time....but I wouldn't go that way; epoll is your best bet
(at least for linux ;-)

> >>> 3) Let's say if we implement websocket server, Can we do the receive
> >>> handling in 1 thread for all the (say max 200000 sockets) and continue
> >>> with send operation using multiple threads. In that case do we need
> >>> any callback to check if the connection is ready?
> >>
> >> Under previous links you'll find everything about this. In short: you
> >> can watch noPoll sockets as regular sockets (in fact they are). Once
> >> movement is detected, call appropriate functions to get data received...
> >>
> >>> And also, would I
> >>> need some locking before sending my data from any thread or its
> >>> already taken care of in noPoll library?
> >>
> >> Ok, we've designed the library so it can work in threaded and
> >> non-threaded scenarios. In this case you must provide the right
> >> functions to let noPoll to create mutexes, destroy, lock and unlock
> >> them... with this:
> >>
> >> http://www.aspl.es/nopoll/html/group__nopoll__support_ga7f2a26a896c1416b23933097a993a435.html#ga7f2a26a896c1416b23933097a993a435
> >>
> >> Then noPoll will use these at the right places...
> >>
> Nice! That's great. So we need to just initialize the global mutex,
> and have to insert my lock/unlock etc API's inside those mutex
> wrappers during 'nopoll_thread_handlers' and noPoll would take care of
> appropriate locking and synchronization no matter which thread is
> accessing the noPoll context at the same time. Please correct me if my
> understanding is wrong here.

That's right.

> >> Let us to know your progress and any product using noPoll. We will be
> >> glad to publish some references about it. BR
> >>
> :) Sure Francis. Would definitely update once we get a go ahead with
> the websocket library.

Best Regards!

> >>> Would really appreciate your responses on the same.
> >>>
> >>> Regards,
> >>> _Ayush
> >>> _______________________________________________
> >>> noPoll mailing list
> >>> noPoll en lists.aspl.es
> >>> http://lists.aspl.es/cgi-bin/mailman/listinfo/nopoll
> >>
> >>
> >>

Francis Brosnan Blázquez <francis.brosnan en aspl.es>
91 134 14 22 - 91 134 14 45 - 91 116 07 57


Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).

Más información sobre la lista de distribución noPoll