3 ms·

> Before, say, drawing on-screen controls, you ask the host for “OSC Suite v1.0” Or for IWebBrowser2, or for EFI_GRAPHICS_OUTPUT_PROTOCOL, or for xdg-shell-v7,

> Before, say, drawing on-screen controls, you ask the host for “OSC Suite v1.0” Or for IWebBrowser2, or for EFI_GRAPHICS_OUTPUT_PROTOCOL, or for xdg-shell-v7, or for EGL_ANDROID_presentation_time. It’s not really an uncommon pattern, is my point. It can be awkward to program against, but part of that is just programming against multiple potential versions of a thing in general. I can’t see the connection with handles, though. Suites/interfaces/protocol/etc. are an ABI stability tool, whereas handles are at most better for testing in that respect compared to plain opaque pointers.

pavlov 3y ago
In my mind, the similarity is that both handles and function suites allow the host runtime to change things around behind your back because you're not holding direct pointers, but instead the access is always within a scope. With a memory handle there's usually an explicit closing call like unlock: uint8_t *theData = LockHandle(h); ... UnlockHandle(h); theData = NULL; With a function suite (they way I've seen them used anyway!), the access might be scoped to within a callback, i.e. you are not allowed to retain the function pointers beyond that: doStuffCb(mgr) { SomeUsefulSuite *suite = mgr->getSuite(USEFUL_V1); if (suite && suite->doTheUsefulThing) suite->doTheUsefulThing(); }
- mananaysiempre 3y ago
  Ah. Yes, that’s quite a bit more specific than what I imagined from your initial description. Doesn’t that mean that you have to unhook all your references from the world at the end of the callback and find everything anew at the start of a new one? (For the most part, of course, that would mean that both the runtime and the plugin would end up using as few references as possible.) What could a runtime want to change in the meantime that pays for that suffering? I can only think of keeping callbacks active across restarts and upgrades, and even then allowing for parts to disappear seems excessive.

pavlov 3y ago

In my mind, the similarity is that both handles and function suites allow the host runtime to change things around behind your back because you're not holding direct pointers, but instead the access is always within a scope. With a memory handle there's usually an explicit closing call like unlock: uint8_t *theData = LockHandle(h); ... UnlockHandle(h); theData = NULL; With a function suite (they way I've seen them used anyway!), the access might be scoped to within a callback, i.e. you are not allowed to retain the function pointers beyond that: doStuffCb(mgr) { SomeUsefulSuite *suite = mgr->getSuite(USEFUL_V1); if (suite && suite->doTheUsefulThing) suite->doTheUsefulThing(); }

mananaysiempre 3y ago
Ah. Yes, that’s quite a bit more specific than what I imagined from your initial description. Doesn’t that mean that you have to unhook all your references from the world at the end of the callback and find everything anew at the start of a new one? (For the most part, of course, that would mean that both the runtime and the plugin would end up using as few references as possible.) What could a runtime want to change in the meantime that pays for that suffering? I can only think of keeping callbacks active across restarts and upgrades, and even then allowing for parts to disappear seems excessive.