Skip to content

Serialize session lifecycle and command submission #10

Description

@protostatis

Context

This is low priority for the intended single-user, sequential workflow, but the session protocol currently breaks under parallel callers or a stop/restart during a long command.

Reproduced behavior

bash test_wait_issues.sh reproduced:

  • T7: simultaneous run calls race on shared cmd.py.tmp; one command can be lost or misdelivered.
  • T8: stop returns while a long exec() is still running, removes the PID file, and a subsequent start can launch a second daemon for the same session.
  • T10: concurrent start calls can launch two daemons.

Expected

A session has exactly one live daemon and accepts at most one command at a time. stop must not report success or release the session while the original daemon remains alive.

Suggested direction

Use a per-session owner lock and readiness marker; atomically claim the idle state before publishing a uniquely named request; preserve the PID file until termination is confirmed, or expose an explicit forced-stop behavior.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions