Add explicit context_id parameter to all hostcalls.
#92
Conversation
While there, add and consistently use `UNKNOWN_RESOURCE_ID` error for when resources are accessed using an unknown ID. Signed-off-by: Piotr Sikora <code@piotrsikora.dev>
| * returns: | ||
| - `i32 (`[`proxy_status_t`]`) status` | ||
|
|
||
| > **Warning** | ||
| > This function has been deprecated in favor of explicit context IDs. | ||
| Changes the effective context to `context_id`. | ||
|
|
||
| This can be used to change active context, e.g. during |
There was a problem hiding this comment.
Perhaps it should be completely removed?
|
|
||
| | Identifier | Name | Values | Deprecated | | ||
| |:----------:|:--------------------------------|:---------------------------------------------------------------------------------------------------|:----------:| | ||
| | 0x1001 | `HOST_TRACKS_ACTIVE_CONTEXT_ID` | When `1`, `context_id` can be set to `0`, which then indicates host-tracked active context ID. | Yes | |
There was a problem hiding this comment.
I originally envisioned this as a helpful step to ease the migration (i.e. SDKs could simply pass 0 as context_id and rely on hosts doing the tracking), but I'm not sure if that's worth it?
There was a problem hiding this comment.
Would the alternative be for SDKs to track and pass explicit context IDs from the get go, as part of initial support for the new ABI version? Unless you think there are tricky cases where it would be hard for an SDK to track, ISTM it's not too much work for SDKs to do as part of the switchover.
|
|
||
| | Identifier | Name | Values | Deprecated | | ||
| |:----------:|:--------------------------------|:---------------------------------------------------------------------------------------------------|:----------:| | ||
| | 0x1001 | `HOST_TRACKS_ACTIVE_CONTEXT_ID` | When `1`, `context_id` can be set to `0`, which then indicates host-tracked active context ID. | Yes | |
There was a problem hiding this comment.
Would the alternative be for SDKs to track and pass explicit context IDs from the get go, as part of initial support for the new ABI version? Unless you think there are tricky cases where it would be hard for an SDK to track, ISTM it's not too much work for SDKs to do as part of the switchover.
|
|
||
| * params: | ||
| - none | ||
| - `i32 (uint32_t) context_id` |
There was a problem hiding this comment.
In hostcalls like this one, which list their param as context_id rather than stream_context_id or plugin_context_id, is it correct to interpret that as meaning that either type of context ID can be passed?
For this hostcall in particular, would passing plugin_context_id to proxy_done be a way of signalling shutdown of the plugin as a whole?
2 participants
While there, add and consistently use
UNKNOWN_RESOURCE_IDerrorfor when resources are accessed using an unknown ID.