Hacker News new | past | comments | ask | show | jobs | submit login

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();
  }



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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: