David F. Skoll wrote: > * mimedefang-multiplexor: New scheduling algorithm tries to keep > commands "sticky". For example, when looking for a slave to run > "recipok", we prefer to use a slave that recently ran "recipok". > NOTE!!! If your filter incorrectly retains state from earlier > callbacks into filter_begin, this scheduling change WILL expose > the bugs in your filter. >
David, Thanks for giving us mimedefang, we all owe you one!!! I'm trying to come up with a way to test this new algorithm before I upgrade production systems. One thought I had was to call exit at the end of each filter and test. Theoretically, the multiplexor would replace the slave so it shouldn't affect operation (other than performance which is not a concern while testing), and each new slave would case loss of state. I think this would show me any problems with my filter without trying to determine whether it works because my filter is correct or I got lucky and reused a slave which is far more likely on my test system. Does this sound reasonable to you? Also, I want to double check that I have a correct understanding of which vars will be set when a slaved is called: Vars created in filter_initialize(). Global vars such as $Sender or @Recipients. Vars that are passed to the function. Does that look right to you? I have been careful not depend on anything other than the vars above, so I think I'll be alright. Thanks, schu _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang