>
> Quick thought: Should be simple to release lock when interacting with network.
I don’t think this will be that simple. The network calls will typically happen
from inside the plugins and we don’t want to make plugin authors responsible
for that.
> Could also have abort signal lockers.
With the decodegroup locking we do have access to all the decoding backend
pids. So we could signal them. But am not sure signaling will work if the
plugin is in the midst of a network
Call.
I agree with Petr. With this decodegroup
Lock implementation we have an inexpensive but workable implementation for
locking around the plugin call. Sure, the abort will be penalized but it’s
bounded by the Wal sender timeout or a max of one change apply cycle.
As he mentioned if we can optimize this later we can do so without changing
plugin coding semantics later.
Regards,
Nikhils
>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
