Skip to content

Conversation

sirosen
Copy link
Member

@sirosen sirosen commented Oct 3, 2025

Introduce the '_resource_owner' internal protocol

Several resources in the SDK now define a tracking protocol to allow
resources to participate in a cascading close() via a GlobusApp.

The design breaks down into two major sections.

Ownership Tracking

  • _resource_owner: BaseClient | None is a new property of transports
  • _resource_owner: GlobusApp | None is a new property of token storage
  • _resource_owner: GlobusApp | None is a new property of clients
  • _owned_clients: MutableSet[BaseClient] is a new property of apps

These are the storage mechanisms being used. The _owned_clients set is
defined as a weakref.WeakSet, meaning that membership in the set will
not prevent garbage collection of the members (which implicitly removes
them).

Each resource "may know its owner" by having the _resource_owner
assigned, and apps keep tabs on "owned clients" (which are otherwise
not associated).

The rules for when these are set are as follows:

  • When an app is attached to a client (as through init) it is stored as
    _resource_owner
  • When an app is attached to a client, the client is added to the app's
    _owned_clients
  • When a client creates a transport, it sets itself as the transport's
    _resource_owner
  • When an app creates a token storage, it sets itself as the token
    storage's _resource_owner

Close Semantics

  • All token storages now define close(), but it is still only
    meaningful for some -- the base version is a no-op
  • BaseClient._close() is a new (private) method which closes the
    underlying transport IFF the client is the owner
  • GlobusApp.close() is a new (public) method which closes (_close())
    all apps owned by the client and any token storage owned by the client
  • GlobusApp supports use as a context manager, with close() on exit

  • Introduce the '_resource_owner' internal protocol
  • Add unit tests for resource ownership + close
  • Make User Guide use GlobusApp context managers
  • Add explicit narrative doc for GlobusApp.close()

Several resources in the SDK now define a tracking protocol to allow
resources to participate in a cascading `close()` via a GlobusApp.

The design breaks down into two major sections.

Ownership Tracking
------------------

- `_resource_owner: BaseClient | None` is a new property of transports
- `_resource_owner: GlobusApp | None` is a new property of token storage
- `_resource_owner: GlobusApp | None` is a new property of clients
- `_owned_clients: MutableSet[BaseClient]` is a new property of apps

These are the storage mechanisms being used. The `_owned_clients` set is
defined as a `weakref.WeakSet`, meaning that membership in the set will
not prevent garbage collection of the members (which implicitly removes
them).

Each resource "may know its owner" by having the `_resource_owner`
assigned, and apps keep tabs on "owned clients" (which are otherwise
not associated).

The rules for when these are set are as follows:
- When an app is attached to a client (as through init) it is stored as
  `_resource_owner`
- When an app is attached to a client, the client is added to the app's
  `_owned_clients`
- When a client creates a transport, it sets itself as the transport's
  `_resource_owner`
- When an app creates a token storage, it sets itself as the token
  storage's `_resource_owner`

Close Semantics
---------------

- All token storages now define `close()`, but it is still only
  meaningful for some -- the base version is a no-op
- `BaseClient._close()` is a new (private) method which closes the
  underlying transport IFF the client is the owner
- `GlobusApp.close()` is a new (public) method which closes (`_close()`)
  all apps owned by the client and any token storage owned by the client
- `GlobusApp` supports use as a context manager, with `close()` on exit
Update all usages of GlobusApps in the User Guide docs to use the
context manager form of app objects.
@sirosen
Copy link
Member Author

sirosen commented Oct 3, 2025

This branch of work was continued, literally (commits preserved) in #1326

@sirosen sirosen closed this Oct 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant