Hi all, I started this slide show with some ideas how we can solve the “90%” of the problem (i.e. making all plugins reloadable, both code and configs). See the link at
https://www.icloud.com/keynote/AwBUCAESENdl8ooGRL1RjGFpC0Jt03saKd2FE7OokWOx4mDdeu2WkoGhPN-GT6KxDq0Sk01DmcUHUWsF7og8i8kJMCUCAQEEIMibNldjSDbtsm5RR0runUjgkB9WK2a2H5OJy1q3jOxs?redirectReason=notFound#Reloading_plugins <https://www.icloud.com/keynote/AwBUCAESENdl8ooGRL1RjGFpC0Jt03saKd2FE7OokWOx4mDdeu2WkoGhPN-GT6KxDq0Sk01DmcUHUWsF7og8i8kJMCUCAQEEIMibNldjSDbtsm5RR0runUjgkB9WK2a2H5OJy1q3jOxs?redirectReason=notFound#Reloading_plugins> This is not complete yet, but looking for input / comments so we can maybe discuss this for the next summit. The big picture idea is that we 1) Load plugin.config and remap.config as a unit. Either file changes, they both reload. 2) These loaded units are ref-counted, on a per-session basis. This means the same plugins / remap rules applies to all transaction on a session. 3) Plugins no longer have to worry about things such as ref-counting their configs / continuations, and we eliminate the (crazy :) time-delayed deletes of remap configurations. This is not 100% compatible with current behavior (remap.config ls per transaction), but I think it’s worth that compromise. I think the above would be fairly straight forward, with a new struct (atomically swappable?) that holds both remap and plugins. I haven’t thought about all potential issues here, and this obviously still doesn’t solve the issue of gracefully restarting the core, but I think this could solve some of the most serious issues we have today (plugin code reload and plugin config reload). Cheers, — Leif
