>
> 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
wantto 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
suresignaling 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
abortwill 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.
