[CRIU] [PATCH 2/3] signalfd: add ability to get signal without removing from the queue

[Pavel Emelyanov]

On 11/29/2012 08:51 PM, Andrey Vagin wrote:
> signalfd should be called with the flag SFD_PEEK.
> 
> The operation read() returns siginfo, but the signal remains in a queue.
> signalfd has an internal offset, which is incremented on each siginfo
> and the next siginfo is choosen according with this offset in the queue.

It's not nice. It's designed for one-shot reading which is not great.
IOW -- I create such fd, then peek one signal, then handle one. The signal
gets removed from queue. Then I get one more signal, but read from this
fd will report nothing, as offset is 1 and doesn't decrease.

> If a signalfd is created with the flag SFD_GROUP, signals will be
> received from a group signal queue.
> 
> If a signalfd is created with SFD_PEEK, read() returns siginfo instead
> of signalfd_siginfo, because signalfd_siginfo is not full.
> For example if a signal has been sent by rt_sigqueueinfo,
> signalfd_siginfo will not contain full data from siginfo.
> 
> si_code is not restricted, it contains SI_CODE, otherwise we can't
> restore siginfo.
> 
> This fuctionality will be used for checkpointing pending signals.
> 
> Signed-off-by: Andrey Vagin <avagin at openvz.org>