On Tue, Dec 25, 2012 at 05:58:03PM +0100, Oleg Nesterov wrote:
> On 12/25, Pavel Emelyanov wrote:
> >
> > On 12/25/2012 07:27 PM, Oleg Nesterov wrote:
> > >
> > > I guess that probably you actually need DUMP, not DEQUEUE. but the
> > > latter is not trivial. However, perhaps we can do this assuming that
> > > all other threads are sleeping and nobody can do dequeue_signal().
> > > Say, we can play with ppos/llseek. If *ppos is not zero,
> > > signalfd_dequeue() could dump the nth entry from list or return 0.
> >
> > This would be perfect, but isn't it better to preserve the pos
> > semantics -- we do know size of entry we're about to copy, we can
> > treat pos as offset in bytes, not in elements.
> 
> nr-of-records looks better (more flexible) than nr-of-bytes to me. And
> perhaps we can also encode private-or-shared into ppos. But I will not
> argue in any case.

Oleg and Pavel, could you look at these two patches. I implemented in them,
what you described here.

> 
> Oleg.
> 
> _______________________________________________
> CRIU mailing list
> CRIU@openvz.org
> http://lists.openvz.org/mailman/listinfo/criu