Re: Advice Required - for avoiding conflict betwen qmail-smtpd, rblsmtpd loaded as shared objects in tcpserver

On 2 April 2017 at 03:32, Erwin Hoffmann <[email protected]> wrote:
> Hi Manvendra (and all other readers),

> actually, Charles spoke out what is common believe: Fork/Exec is an operation to lightweight to invest a lot of efforts to improve it. In particular considering the benefits of an uncompromised and clean environment (unlike a thread). HW multithreading (lots of CPUs) will again be in favor of this decision.
>
> I'm also not so positive regarding shared modules in qmail. Clearly, an entire new architecture paradigm should be substantiated with numbers and profiling is certainly necessary. However, I don't see (though without numbers by myself) a great need to change qmail's internal working structure; in particular regarding portability.
>

I do have a peculiar situation. Unlike qmail/netqmail, I have too many
control files being opened in qmail-smtpd. These get loaded again and
again for each and every mail that comes into the system using SMTP.
This whole idea of using dlopen() was just to move the loading all the
control files in the main() function of tcpserver. Subsequent calls to
qmail-smtpd will happen by calling a fuction smtp_init() instead of
exec(). I do agree that fork()/exec() gives you an uncompromised
environment. The other advantage of having shared modules or plugins
is the ability to add functionality without modifying the original
code.

> Currently, Kai Peter (eqmai) and me (s/qmail) are going to bundle our activities to focus on an 'alternative' qmail to feed the need for a concurrent and stable replacement for qmail. We've had this discussion months ago, and I rather invite you to participate again (let's do that off-line).

Sure Eh, There are few things I an definitely bring to the table (rpm,
debian and docker images).

-- 
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C