Skip to content
Snippets Groups Projects

Destroy the runners cleanly when shutting down the engine.

Merged Pedro Gonnet requested to merge runners_clean_stop into master
1 unresolved thread

Adds a new engine_step_prop_stop which makes the runners quit if set. engine_clean now sets the prop, releases the runners, and pthread_joins them.

Fixes #559 (closed).

Edited by Peter W. Draper

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
6032 6032 */
6033 6033 void engine_clean(struct engine *e) {
6034
6035 for (int i = 0; i < e->nr_threads; ++i) {
6034 /* Start by telling the runners to stop. */
6035 e->step_props = engine_step_prop_done;
6036 swift_barrier_wait(&e->run_barrier);
6037
6038 /* Wait for each runner to come home. */
6039 for (int k = 0; k < e->nr_threads; k++) {
6040 if (pthread_join(e->runners[k].thread, /*retval=*/ NULL) != 0)
6041 error("Failed to join runner %i.", k);
6036 6042 #ifdef WITH_VECTORIZATION
6037 cache_clean(&e->runners[i].ci_cache);
6038 cache_clean(&e->runners[i].cj_cache);
6043 cache_clean(&e->runners[k].ci_cache);
  • Just one thought. Wouldn't it be safer to wait for all the runners to exit before proceeding to clean up the caches, i.e. put the caches in a second loop?

  • Author Developer

    Not really... The caches are runner-specific, so nobody else should be able to access them except for the runner itself. At least that's my understanding of how they are used.

  • Yes, so aren't we, in principle anyway, removing something a runner could be using before we know for certain it has exited (since k can be less than the runner in question). Not going to happen if all threads are at the barrier, but the sanitizer broke that contract somehow.

  • Author Developer

    Exactly, the pthread_join above blocks until the runner's thread has exited :)

  • Thanks, forgot that was a blocking call. Makes sense now.

  • Please register or sign in to reply
  • OK, all looks to be working and the sanitizer is back to reporting embarrassing leaks, rather than embarrassing crashes. Accepting.

  • Peter W. Draper mentioned in commit 535917ea

    mentioned in commit 535917ea

  • Please register or sign in to reply
    Loading