[NicolasFussberger]

Before: 3-way handshake

   Launch Manager                          App
   ──────────────                          ───
   send_sync_.wait   ◀── send_sync_.post ──
   reply_sync_.post  ── reply_sync_.post ─▶ reply_sync_.wait
   send_sync_.wait   ◀── send_sync_.post ──
   sem_destroy(send_sync_)
   sem_destroy(reply_sync_)

This introduces some potential problems that are unnecessary as the reply_sync_.wait and the second send_sync_.wait use fixed wait times of 1s and 100ms which might be off for a system under heavily load.
This can lead to cases where although the App has reported kRunning (first semaphore) it still fails in the daemon because the 2nd and 3rd semaphores timed out.

Simplified behavior:

  Launch Manager                          App
   ──────────────                          ───
   send_sync_.wait   ◀── send_sync_.post ──
          ⋮
   (app terminated and reaped)
   sem_destroy(send_sync_)

Single semaphore to post kRunning.
Semaphore is destroyed when the process terminated.

[danth]

What was the reason for using multiple messages originally?

[NicolasFussberger]

What was the reason for using multiple messages originally?

AFAIK the reasons were:

• ReportRunning could return an error code to the user, so there needed to be an explicit acknowledgement to the application process that it was received (now its a void method, if it would not work the ready timeout in LM would eventually catch it)
• The third message was to be sure that application is no longer waiting on the semaphore so it served as a trigger to delete the semaphore in shared memory (now its just removed when the process dies)

[github-actions]

Documentation preview for this pull request is available at:
pr-829: https://eclipse-score.github.io/lifecycle/pr-829/