* [C/R] threaded application
@ 2009-05-17 2:31 Sukadev Bhattiprolu
[not found] ` <20090517023125.GA30716-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 2+ messages in thread
From: Sukadev Bhattiprolu @ 2009-05-17 2:31 UTC (permalink / raw)
To: Oren Laadan; +Cc: Containers
Probably premature :-) but tried to C/R a simple threaded application
(running as container-init).
First got an -EINVAL due to following check in may_checkpoint_task():
/*
* FIX: for now, disallow siblings of container init created
* via CLONE_PARENT (unclear if they will remain possible)
*/
if (ctx->root_init && t != ctx->root_task &&
t->real_parent == ctx->root_task->real_parent)
Assuming we are unintentionally excluding CLONE_THREAD with the
above check, I added a check for tgid:
if (ctx->root_init && t != ctx->root_task &&
t->real_parent == ctx->root_task->real_parent &&
t->tgid != ctx->root_task->tgid) {
This got past the -EINVAL but the test failed the ckpt_obj_contained() check.
c/r: FILE users 2 != count 6 objref 9
The main-thread opened a single file (log file). The other threads don't
write to it (yet). The count '6' corresponds to the number of threads in
the application.
I suspect that C/R code is incrementing obj->users once per thread for
the log file even though the threads share the file_struct reference.
(pthread_create() sets CLONE_FILES so the file_struct is shared between
threads).
Will post my test programs to Serge's new git-tree next week.
Sukadev
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [C/R] threaded application
[not found] ` <20090517023125.GA30716-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
@ 2009-05-17 18:29 ` Oren Laadan
0 siblings, 0 replies; 2+ messages in thread
From: Oren Laadan @ 2009-05-17 18:29 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: Containers
Suka,
Thanks for the report.
Sukadev Bhattiprolu wrote:
> Probably premature :-) but tried to C/R a simple threaded application
> (running as container-init).
>
> First got an -EINVAL due to following check in may_checkpoint_task():
>
> /*
> * FIX: for now, disallow siblings of container init created
> * via CLONE_PARENT (unclear if they will remain possible)
> */
> if (ctx->root_init && t != ctx->root_task &&
> t->real_parent == ctx->root_task->real_parent)
>
> Assuming we are unintentionally excluding CLONE_THREAD with the
> above check, I added a check for tgid:
>
> if (ctx->root_init && t != ctx->root_task &&
> t->real_parent == ctx->root_task->real_parent &&
> t->tgid != ctx->root_task->tgid) {
>
> This got past the -EINVAL but the test failed the ckpt_obj_contained() check.
Yes, I see no reason to prevent multi-threaded container init.
Will add this to the ckpt-v15-dev git tree.
>
> c/r: FILE users 2 != count 6 objref 9
>
> The main-thread opened a single file (log file). The other threads don't
> write to it (yet). The count '6' corresponds to the number of threads in
> the application.
>
> I suspect that C/R code is incrementing obj->users once per thread for
> the log file even though the threads share the file_struct reference.
> (pthread_create() sets CLONE_FILES so the file_struct is shared between
> threads).
>
Indeed, the current code doesn't yet handle files_struct as a
shared object, so anything with CLONE_FILES isn't done correctly.
That's on the todo-list...
Oren.
> Will post my test programs to Serge's new git-tree next week.
>
> Sukadev
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-05-17 18:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-17 2:31 [C/R] threaded application Sukadev Bhattiprolu
[not found] ` <20090517023125.GA30716-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-17 18:29 ` Oren Laadan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.