[fpc-devel] Linux Signals

[Henry Vermaak]

On 2 January 2011 15:06, Andrew Brunner <andrew.t.brunner at gmail.com> wrote:
> 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.

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