Skip to content

Conversation

@TheBlueMatt
Copy link
Contributor

Instead of passing a StartShutdown reference all the way up from
txdb, give ShowProgress a "cancelable" boolean, as StartShutdown
is pretty much always what you'll want to use to cancel. Use the
same boolean to allow cancel during initial block verification.

Copy link
Contributor

@ryanofsky ryanofsky Jul 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't you need to invoke setBreakAction(nullptr) here when cancel_possible is false?

Maybe better would be to get rid of this std::function madness and replace the SplashScreen::breakAction pointer with a simpler boolean std::atomic<bool> m_cancel_possible which you can just assign directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice.

@TheBlueMatt TheBlueMatt force-pushed the 2017-07-upgrade-cancel-nits branch 2 times, most recently from 20e66f7 to 1d62f6e Compare July 7, 2017 21:36
@fanquake fanquake added the GUI label Jul 7, 2017
@jonasschnelli
Copy link
Contributor

Makes sense. I guess I over-engineered the flexible callback (I thought we should have a way to not only shutdown and have the future option to "continue" but this really makes little sense).

utACK 1d62f6e

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 1d62f6e


/** Sets the break action */
void setBreakAction(const std::function<void(void)> &action);
/** Sets if cancel is currently possible */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd consider replacing "cancel possible" with "shutdown possible" everywhere in this PR. The function this is controlling is called StartShutdown. The display text is press q to shutdown. Why should this thing be named differently?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"shutdown" is always possible (just may be slow), what you care about is cancelling the currnent "in progress" thing (and shutting down). I dont really care, but also dont think its particularly unclear?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont really care, but also dont think its particularly unclear?

It's unclear to me what the flag is supposed to indicate or why it wouldn't always be true if shutdown is always possible. Maybe it should be called fast_shutdown_possible if that's what it actually means. Acked this because the PR is definitely a simplification, but I don't think the code or the reason for preventing the quit option from working after the upgrade is clear. I think better naming could help.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some additional comments. I'm not really sure if thats a better name, though I agree cancel_possible is a bit strange.

@sipa
Copy link
Member

sipa commented Jul 11, 2017

This begs the question whether we shouldn't just have 'q for shutdown' always available? Maybe in some cases there is some initializationstep-specific cleanup, but there shouldn't be much as we're always allowed to crash anyway.

@TheBlueMatt
Copy link
Contributor Author

@sipa yea, I thought about that. We should maybe move the boolean to just change the message to "will complete later if you shutdown now". I still think this is a nice cleanup, and given we're already in freeze for 0.15 it'd be too late to make that change for 0.15. If this sits for the next month without any movement I'll make that change for 16.

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK d1db1f1

@sipa
Copy link
Member

sipa commented Jul 15, 2017

Tested. Segfaults when cancelling during upgrade:

Thread 4 "bitcoin-shutoff" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe117d700 (LWP 6034)]
CCoinsViewCache::DynamicMemoryUsage (this=0x0) at coins.cpp:40
40	    return memusage::DynamicUsage(cacheCoins) + cachedCoinsUsage;
(gdb) bt
#0  CCoinsViewCache::DynamicMemoryUsage (this=0x0) at coins.cpp:40
#1  0x0000555555850c4e in FlushStateToDisk (chainparams=..., state=..., mode=mode@entry=FLUSH_STATE_ALWAYS, nManualPruneHeight=nManualPruneHeight@entry=0) at validation.cpp:1899
#2  0x00005555558521bc in FlushStateToDisk () at validation.cpp:1969
#3  0x00005555556f6bf5 in Shutdown () at init.cpp:219
#4  0x00005555555d0ed0 in BitcoinCore::shutdown (this=0x55555698e330) at qt/bitcoin.cpp:309
#5  0x00007ffff5962359 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff689835c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x00007ffff689fb11 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007ffff59358a0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007ffff593802d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007ffff5989b03 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007ffff1644377 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff16445e0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff164468c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff5989f0f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff593388a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007ffff5760fe3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007ffff5765c98 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007ffff504e6da in start_thread (arg=0x7fffe117d700) at pthread_create.c:456
#19 0x00007ffff387ed7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105

@TheBlueMatt
Copy link
Contributor Author

@sipa hmm, I could be wrong but that strikes me as an issue that would also be present prior to the changes in this PR.

@TheBlueMatt
Copy link
Contributor Author

TheBlueMatt commented Jul 16, 2017

@sipa yes, that appears to be another bug introduced in #10179 after d6af06d changed some semantics, I'll fix it in #10758 with my other pile of fixes that are gonna need to land for 15 anyway.

@jj1010
Copy link

jj1010 commented Jul 16, 2017 via email

{
breakAction = action;
}
InitMessage(splash, title + strprintf("%d", nProgress) + "%" +
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please put a space or a newline between the title and the progress.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, cleaned it up.

@TheBlueMatt TheBlueMatt force-pushed the 2017-07-upgrade-cancel-nits branch from d1db1f1 to 59147fa Compare July 16, 2017 23:21
Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 59147fa4d616e8f4ca05365957444cc74a30af51. Only change since last review is rearranged progress string.

@achow101
Copy link
Member

achow101 commented Aug 7, 2017

Having this would make fixing #10992 much easier.

@jonasschnelli
Copy link
Contributor

@TheBlueMatt: can you rebase?

@TheBlueMatt TheBlueMatt force-pushed the 2017-07-upgrade-cancel-nits branch from 59147fa to e7797eb Compare August 16, 2017 21:37
@TheBlueMatt
Copy link
Contributor Author

"Rebased", but also just dropped the "cancelable" idea (as @sipa originally suggested) and always allow shutdown, using the passd-up boolean just to change the message to inform the user the current action will resume on restart.

@sipa
Copy link
Member

sipa commented Aug 16, 2017

@TheBlueMatt There may be a use for keeping the cancellation boolean, so the interface can be reused to make the "rescanning" dialog in the GUI interruptible (cc @achow101).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be set but not actually used anywhere?

@TheBlueMatt
Copy link
Contributor Author

@sipa that is going to need a very different interface anyway, as StartShutdown() is not appropriate there (better to separate the interface between during-init progress and other-things progress IMO).

@jonasschnelli
Copy link
Contributor

@achow101: for the rescan progress work, would having this PR be better or not having it?

@achow101
Copy link
Member

For rescan progress we needed the cancellation boolean, But since that has been dropped, it doesn't matter.

Instead of passing a StartShutdown reference all the way up from
txdb, give ShowProgress a "resumeable" boolean, which is used to
inform the user if the action will be resumed, but cancel is always
allowed by just calling StartShutdown().
@TheBlueMatt
Copy link
Contributor Author

@achow101 well the cancellation boolean wouldn't have really helped, because the cancellation boolean in the previous version of this PR indicated to the GUI that it can call StartShutdown() to cancel, which is most definitely not what you want to do when its a rescan we're talking about.

@ryanofsky thanks, fixed.

@TheBlueMatt TheBlueMatt force-pushed the 2017-07-upgrade-cancel-nits branch from e7797eb to ee4d149 Compare August 21, 2017 00:04
Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK ee4d149. Changes since previous ACK are getting rid of cancel_possible bool to make 'q' shortcut to work unconditionally, and adding resume_possible bool to give an indication of when efficient resumes are possible.

@achow101 implemented rescan cancellation in #11200 which is compatible with this PR (though doesn't merge cleanly).

@jonasschnelli
Copy link
Contributor

Tested ACK ee4d149

@jonasschnelli jonasschnelli merged commit ee4d149 into bitcoin:master Sep 7, 2017
jonasschnelli added a commit that referenced this pull request Sep 7, 2017
… "cancelable"

ee4d149 Drop upgrade-cancel callback registration for a generic "resumeable" (Matt Corallo)

Pull request description:

  Instead of passing a StartShutdown reference all the way up from
  txdb, give ShowProgress a "cancelable" boolean, as StartShutdown
  is pretty much always what you'll want to use to cancel. Use the
  same boolean to allow cancel during initial block verification.

Tree-SHA512: 515817aaa4b9e3e856200e00be9c2d44ecfa2d4f288fe3e02116105fe85de2650c13076ee7e45396ec1ce6ab45e53b0477cddda7cfdee5b3bd0589cb81a4c346
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Dec 9, 2019
…generic "cancelable"

ee4d149 Drop upgrade-cancel callback registration for a generic "resumeable" (Matt Corallo)

Pull request description:

  Instead of passing a StartShutdown reference all the way up from
  txdb, give ShowProgress a "cancelable" boolean, as StartShutdown
  is pretty much always what you'll want to use to cancel. Use the
  same boolean to allow cancel during initial block verification.

Tree-SHA512: 515817aaa4b9e3e856200e00be9c2d44ecfa2d4f288fe3e02116105fe85de2650c13076ee7e45396ec1ce6ab45e53b0477cddda7cfdee5b3bd0589cb81a4c346
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Jan 3, 2020
…generic "cancelable"

ee4d149 Drop upgrade-cancel callback registration for a generic "resumeable" (Matt Corallo)

Pull request description:

  Instead of passing a StartShutdown reference all the way up from
  txdb, give ShowProgress a "cancelable" boolean, as StartShutdown
  is pretty much always what you'll want to use to cancel. Use the
  same boolean to allow cancel during initial block verification.

Tree-SHA512: 515817aaa4b9e3e856200e00be9c2d44ecfa2d4f288fe3e02116105fe85de2650c13076ee7e45396ec1ce6ab45e53b0477cddda7cfdee5b3bd0589cb81a4c346
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants