Skip to content

Conversation

@kastiglione
Copy link
Contributor

@kastiglione kastiglione commented Mar 20, 2025

Depends on #80183.

@kastiglione
Copy link
Contributor Author

@swift-ci smoke test

@kastiglione
Copy link
Contributor Author

oh wait, I bet I need more plumbing…

@kastiglione
Copy link
Contributor Author

yep, I missed swift_reflection_asyncTaskInfo.

From #77167 (review):

We should probably add things to the C interface as well, but that's harder since we don't want to break the ABI. Not sure what the best approach is there, we can add a swift_reflection_asyncTaskInfo2 with the new stuff, but that could grow a lot of variations.

@kastiglione kastiglione reopened this Mar 20, 2025
@mikeash
Copy link
Contributor

mikeash commented Mar 21, 2025

Adding a new struct and a new function every time we want to add a field is going to be a pain.

I'm thinking, for new C Remote Mirror APIs, we should switch to returning a pointer to a struct instead of a struct. We have allocateTemporaryObject in the wrapper code to make it easy to return a pointer that's valid until the next call. Then we can add fields to existing structs returned in this manner without breaking old clients. We can put a version number at the front of each one so that new clients know which fields are valid and which should be ignored. We'll still need a 2 variant for this call, and any others which we want to evolve, but at least it would stop there.

Alternatively, we could have the caller pass a buffer and a size, and we fill out as much of the struct as will fit. This would be more awkward to call but maybe a bit more efficient.

@kastiglione
Copy link
Contributor Author

kastiglione commented Mar 21, 2025

That sounds like a good solution @mikeash.

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.

4 participants