[fpc-devel] Linux Signals

[Andrew Brunner]

On Sun, Jan 2, 2011 at 5:24 AM, Nikolai Zhubr <n-a-zhubr at yandex.ru> 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.

As Michael pointed out, and he and I both would benefit from having
socket signaling under Linux, that employ no (rounding or transversing
of socket elements) as it would be the most ideal environment.