ICRAR / ngas

70%

master: 69%

LAST BUILD ON BRANCH correct-janitor-init

branch: correct-janitor-init

CHANGE BRANCH

x

Reset

• correct-janitor-init
• master
• v11
• next
• macos-hostnames
• smtp-testing
• plugins-importing
• clone-order-fixes
• clone-fix
• various_improvements
• volumes
• none-reg-parameters
• relaxed-netifaces
• fs-monitor
• subscription_thread_ng
• macos-travis-fix
• bbcp_fixes
• fits_optional_arcfile
• travis-fixes
• coverage-stability
• c_client_warning_fixes
• centos7-compatibility-changes
• fs-monitor-fixes
• small-improvements
• no-create-venv
• python-client-improvements
• doc-updates
• netifaces-fix
• janitor-thread-startup
• stream-proxy-request
• separate-test-servers
• partner_sites
• travis-errors
• github-actions
• avoid-installing-bsddb3-in-py27
• subscription-def
• macos-travis-update
• issue-38
• aiosmtpd
• issue-13
• NGAS-163
• correct-logging-c
• issue-44
• improve-register-error-message
• remove-test-generic-registration-plugin
• issue-50
• issue-51
• servers-flag
• update-travis-matrix
• py39
• travis-focal
• uwe-fixes
• requests-pinning
• fix-requests-dependency-specs
• 98-query-ignore
• release-12.0
• v12.0
• v12
• document-future-removal-of-27
• remove-2.7-builds
• issue-103
• py311
• richer-archiving-event
• docs-fix
• direct_sql

Start communication thread before janitor process

The main server process and the janitor process communicate through a
pair of Queues. The handling of this communication on the main server
process happens on a separate thread, which we used to start after we
spawned the janitor process. This sequence opened the door for a race
condition where the janitor process would try to read from the
corresponding queue, but the main server wouldn't have put any item on
it yet as the communication thread wouldn't have started yet.

This commit fixes this situation by starting the communication thread
before spawning the janitor process. Since we are not waiting for the
communication thread to be up and running (only starting it) there is
still some chance that the original problem could occur, but with a much
lesser probability.

This addresses the problem originally reported in #78.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>