On 10 May 2005, at 16:21, Elliot F wrote:
I'm looking at moving to the high_perf branch, or at least doing dev on it, as it looks promising and educational. I have used some of my plugins for "normal" qpsmtpd with high_perf, but blocking occurs. While this isn't an issue for a smaller server, I imagine it would scale rather poorly.
What recommendations do you have for writing asynchronous plugins? Is that what would be needed in this case, or am I making it overly complex?
I've mentioned in previous threads about this - the calls to plugins don't *have* to be async, but it helps with performance. The -j option is in there to help with plugins that aren't async (basically using forking to help with the non-async-ness of things).
Right, it works (like I said above), it just doesn't scale. The -j option seems like a good workaround, but I would imagine performance would be peak with everything being async.
In terms of what is required you need to look at where in your plugins you send off a query to a remote "thing" and wait for results to come back. This needs to be split into two separate plugin phases - one to send the request (and block the client until the response comes back) and another to pickup the answer. See the DNSBL plugin for an example. I'm not yet sure how something more complex like the spamd plugin would work, but I imagine it would be fairly similar.
I see that the module being used is specific to the Danga module. I'll let you know how the async mode of perl-ldap goes.
The only slightly unfortunate thing is that some plugins just can't work this way - e.g. anything that must work at data_post I'm struggling to see how we can make non-blocking when perl has no continuations. Any bright ideas there would be most helpful. Also anything that doesn't allow you to process a raw socket (because it has to go into our event loop) won't work.
Matt.
