On Fri, 14 Dec 2018 09:50:37 -0500
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Fri, 14 Dec 2018 12:52:34 +0000
> Yordan Karadzhov <ykaradzhov@xxxxxxxxxx> wrote:
>
> > So far, when searching we lock only the text field of the searching
> > panel. This may create a deadlock (as reported by Steven) in the case
BTW, we should probably use the normal way of documenting "reported
by", which would be (see below).
> > when the user presses "Next" or "Prev." button in the same time when
> > a parallelized search is in progress. This patch aims to protect
> > against such a deadlock by locking all components of the panel, except
> > the "Stop search" button.
> > The text panel gets locked only during the actual searching.
> >
Reporte-by: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx>
> > Signed-off-by: Yordan Karadzhov <ykaradzhov@xxxxxxxxxx>
> > ---
> > kernel-shark-qt/src/KsTraceViewer.cpp | 27 +++++++++++++++++++--------
> > kernel-shark-qt/src/KsTraceViewer.hpp | 2 ++
> > 2 files changed, 21 insertions(+), 8 deletions(-)
> >
> Can we add two helper functions and use that instead?
>
> void KsTraceViewer::_searchPanelLock(void)
> {
> _lockSearchPanel(true);
> }
>
> void KsTraceViewer::_searchPanelUnlock(void)
> {
> _lockSearchPanel(false);
> }
>
> This its more in line with the lock / unlock paradigm than passing in
> true and false.
>
I may apply this series anyway, and we could just add the helper
functions in a separate patch.
-- Steve
|