On Mon, May 20, 2013 at 10:09:20AM -0600, Eric Blake wrote:
> On 05/20/2013 03:26 AM, Daniel P. Berrange wrote:
> > It is worse than that - you can't simply ignore ESRCH. In the same way
> > that existing processes can exit, new processes can come into live.
> > The virCgroupMoveTask method doesn't take any of this into account.
> >
>
> Are you talking about the potential for reusing a pid? Remember,
> cgroups is Linux only, and on Linux, we know the kernel behavior - pids
> (well, really thread ids) are assigned sequentially to the next
> available opening, and reusing a tid requires cycling through the entire
> pid space, something that can't happen in a short amount of time.
>
> The problem of pid recycling is more prevalent on other systems, like
> mingw, where pids are not assigned sequentially, and really can be
> reused the very next instruction after a previous process pid has been
> reclaimed. But since we know Linux does not have that behavior, is it
> really a problem for us?
>
> Ignoring ESRCH will solve the problem of a thread that dies between read
> and write, but like you said, won't solve the problem between a thread
> being created between read and write. For that, you'd have to
> repeatedly read the source file until it is empty.
No, i mean that the code does
pids = read(tasks file in old group)
write(pids, tasks file in new group)
In between step 1 and 2, more tasks can have been added to the
old group. So you'll not have moved everything out of the old
group when you're done.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list