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

[Pavel Emelyanov]

On 11/29/2012 10:54 PM, Andrew Vagin wrote:
> 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

where can the peek_off be modified?

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