On Sat, May 11, 2024 at 11:45:33AM +0500, Andrey M. Borodin wrote:
> I see that you store condition in private_data. So "private" means
> that this is a data specific to extension, do I understand it right?
Yes, it is possible to pass down some custom data to the callbacks
registered, generated in a module. One example would be more complex
condition grammar, like a JSON-based thing. I don't really see the
need for this amount of complexity in the tree yet, but one could do
that outside the tree easily.
> As long as I started anyway, I also want to ask some more stupid
> questions:
> 1. Where is the border between responsibility of an extension and
> the core part? I mean can we define in simple words what
> functionality must be in extension?
Rule 0 I've been using here: keep the footprint on the backend as
simple as possible. These have as absolute minimum requirement:
- A function name.
- A library name.
- A point name.
The private area contents and size are added to address the
concurrency cases with runtime checks. I didn't see a strong use for
that first, but Noah has been convincing enough with his use cases and
the fact that the race between detach and run was not completely
closed because we lacked consistency with the shmem hash table lookup.
> 2. If we have some concurrency issues, why can't we just protect
> everything with one giant LWLock\SpinLock. We have some locking
> model instead of serializing access from enter until exit.
This reduces the test infrastructure flexibility, because one may want
to attach or detach injection points while a point is running. So it
is by design that the LWLock protecting the shmem hash table is not hold
when a point is running. This has been covered a bit upthread, and I
want to be able to do that as well.
--
Michael
