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

[Andrew Vagin]

On Thu, Nov 29, 2012 at 09:04:11PM +0400, Pavel Emelyanov wrote:
> 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.

signalfd can create a new file descriptor or can modify an existent
descriptor. So signalfd for an existen fd can reset peek_offset. I think it
will be enough.

> 
> > 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>