June 22, 2021 11:14 PM, "Aisha Tammy" <openbsd.t...@aisha.cc> wrote:
>> [...] >> >> WRT to handshake, it has multiple uses ranging from ensuring the addons get >> their configuration >> from the daemon to synchronising the daemon start with addons readiness. >> Remember, we didn’t have this with filters and realised we couldn’t do >> without, it is the same for >> tables, they need to get their “table name” at start so we need the daemon >> to pass them, and we >> also need the daemon to not start using them before they are ready. > > I am unsure what you mean by a handshake. > sure, so let's look at procexec for filters: - when the server starts, it forks the filters and begins a handshake with each of them, emitting the following (for example): config|smtpd-version|6.6.1 config|smtp-session-timeout|300 config|subsystem|smtp-in config|ready - when the filter receives the last line, it knows the server is done and it is its turn, it emits the following: register|report|smtp-in|link-connect register|ready - at this point the handshake is over, the server is ready and the filter is ready too, they are both in a known state and synchronised before data flows to the filter. The procexec tables should have a similar handshake to allow the server to pass them information and make sure they are synchronised. The only difference with filters would be that table would have a different "register"" line in the handshake but the config part should be similar. This would an addon to implement both a filter and a table by registering for filtering, and providing a lookup backend for example. > Would something like the following be good - on exec the table process has to > print out a string > "TABLE-READY" which ensures us that the process is ready. > Almost, on exec the daemon prints the config bits (exactly like it does for filter), then it reads from the table backend for a register|ready, but yes you have the idea. > I am not exactly sure how I would implement this, my guess would be to use > event(3) with EV_READ on > backend_r (or something like that). > I haven't looked at this code in over a year now so I'm not sure what the right way of doing it is on top of my head, but looking at how filters are handled is a good startint point.