On 2 January 2011 15:06, Andrew Brunner <[email protected]> wrote: > On Sun, Jan 2, 2011 at 5:24 AM, Nikolai Zhubr <[email protected]> wrote: >> Formally yes maybe, but Andrew probably meant just avoiding some horrible >> CPU-burning busy-loop. >> >> Despite of the similar name (epoll), substantial shortcomings of classical >> polling scheme are gone. Say, you need not use a timeout to be able to >> handle any non-socket events like you were forced with select(), you can >> wait on descriptors of different types if you wish to, and you don't have to >> pass huge arrays all the way. > > > >From reading up on ePoll I came to understand that there is was a > period in time, about 3 years ago where there was a push for restful > event driven signals for sockets. (SIGPOLL) is/was existing *nixs > that have proven methods for socket signals on some platforms. Linux > (at least my Ubuntu 10.10) handles SIGPOLL as SIGIO and waits for data > ending in CRLF before sending my pid the signal. Having the kernel > send me such a signal with the socket handle would be the most ideal > situation because I already have core classes that organize/manage > sockets in a high-scale, thread-safe way.
What is stopping you from writing your own code that employs epoll in a thread to notify you of these events? You can always look to libevent for inspiration: http://en.wikipedia.org/wiki/Libevent. They have implemented this for a wide variety of back-ends. Henry _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
