| Message ID | 20221111185849.2458457-2-jose.quaresma@foundries.io |
|---|---|
| State | New |
| Headers | show |
| Series | [bitbake-devel,1/2] build: log the lockfiles in use with debug | expand |
On Fri, 2022-11-11 at 18:58 +0000, Jose Quaresma wrote: > This improve the bitbake UI when there are tasks with > lockfiles waiting to run. > > In such cases one or more tasks are waiting because > there is another one with the lock acquired. > The bitbake UI shows that all the tasks is running > which is not true and can confuse the user. > > This patch will shows what are the task that have the lock > acquired. > > Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> > --- > lib/bb/build.py | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lib/bb/build.py b/lib/bb/build.py > index ae781c8c..6c0b07a1 100644 > --- a/lib/bb/build.py > +++ b/lib/bb/build.py > @@ -253,6 +253,9 @@ def exec_func(func, d, dirs = None): > pass > > with bb.utils.fileslocked(lockfiles): > + if lockfiles: > + bb.verbnote("Task locked with lockfiles") > + > if ispython: > exec_func_python(func, d, runfile, cwd=adir) > else: Can you show what the console looks like with this active? Whilst I understand there is a usability issue here, I'm not sure printing this in the task which has the locks is going to be particularly helpful in this way. Instead the user really wants to know the other tasks are waiting on a lockfile? Cheers, Richard
Richard Purdie <richard.purdie@linuxfoundation.org> escreveu no dia sexta, 11/11/2022 à(s) 23:01: > On Fri, 2022-11-11 at 18:58 +0000, Jose Quaresma wrote: > > This improve the bitbake UI when there are tasks with > > lockfiles waiting to run. > > > > In such cases one or more tasks are waiting because > > there is another one with the lock acquired. > > The bitbake UI shows that all the tasks is running > > which is not true and can confuse the user. > > > > This patch will shows what are the task that have the lock > > acquired. > > > > Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> > > --- > > lib/bb/build.py | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/lib/bb/build.py b/lib/bb/build.py > > index ae781c8c..6c0b07a1 100644 > > --- a/lib/bb/build.py > > +++ b/lib/bb/build.py > > @@ -253,6 +253,9 @@ def exec_func(func, d, dirs = None): > > pass > > > > with bb.utils.fileslocked(lockfiles): > > + if lockfiles: > > + bb.verbnote("Task locked with lockfiles") > > + > > if ispython: > > exec_func_python(func, d, runfile, cwd=adir) > > else: > > Can you show what the console looks like with this active? Whilst I > understand there is a usability issue here, I'm not sure printing this > in the task which has the locks is going to be particularly helpful in > this way. Instead the user really wants to know the other tasks are > waiting on a lockfile? > > Cheers, > > Richard > > For instance if we use the lockfiles in do_compile for clang and rust-native i.e: do_compile[lockfiles] += "$TMP/mylockfiles" Running bitbake tasks with the lockfiles i.e: bitbake clang rust-native -c do_compile -f The UI will show: NOTE: Executing Tasks NOTE: clang-14.0.3-r0 do_compile: Task locked with lockfiles Setscene tasks: 168 of 168 Currently 2 running tasks (776 of 777) 99% |################################################### | 0: rust-native-1.59.0-r0 do_compile - 2m22s (pid 48002) 1: clang-14.0.3-r0 do_compile - 2m22s (pid 51040) 8% |######## Where the clang task is running and the rust-native is waiting (what is not said anywhere, as you noted) After some time when the clang compile task ends we get: NOTE: Executing Tasks NOTE: clang-14.0.3-r0 do_compile: Task locked with lockfiles NOTE: rust-native-1.59.0-r0 do_compile: Task locked with lockfiles Setscene tasks: 168 of 168 Currently 1 running tasks (777 of 777) 99% |################################################### | 0: rust-native-1.59.0-r0 do_compile - 1m30s (pid 48002) 5% |######## But I agree with you that this is not the best approach to fix this UI issue because we know what is the task that has the lock but not the ones waiting for it. Anyway without this change the situation is even worse and this was the simplest and fastest way I found. Jose
diff --git a/lib/bb/build.py b/lib/bb/build.py index ae781c8c..6c0b07a1 100644 --- a/lib/bb/build.py +++ b/lib/bb/build.py @@ -253,6 +253,9 @@ def exec_func(func, d, dirs = None): pass with bb.utils.fileslocked(lockfiles): + if lockfiles: + bb.verbnote("Task locked with lockfiles") + if ispython: exec_func_python(func, d, runfile, cwd=adir) else:
This improve the bitbake UI when there are tasks with lockfiles waiting to run. In such cases one or more tasks are waiting because there is another one with the lock acquired. The bitbake UI shows that all the tasks is running which is not true and can confuse the user. This patch will shows what are the task that have the lock acquired. Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io> --- lib/bb/build.py | 3 +++ 1 file changed, 3 insertions(+)