Re: [Mimedefang] MIMEDefang 2.48 is available
Why is it a problem to do this outside of filter_initialize? Because after we fork a child, we close() all unneeded file descriptors (see mimedefang-multiplexor.c, around line 2193. This will most likely close the file descriptor out from under Perl -- that is, Perl will think the descriptor is open, but the C code will have closed it. OK, just to be sure - It's safe to open descriptors on a per slave basis as long as it in filter_initialize, filter_begin, filter, filter_end? It's not safe to open file descriptors in the main body (outside of the callback functions) of the perl filter because these are only called once and will get closed (by subsequent slaves calling close(2) post fork)? Equally it's also not safe to open file descriptors in the other pre-body filter callback functions (such as filter_sender) because it cannot be gauranteed that the same slave will process the body (in the same way global vars cannot be used in these)? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.48 is available
On Wed, 3 Nov 2004, Chris Masters wrote: OK, just to be sure - It's safe to open descriptors on a per slave basis as long as it in filter_initialize, filter_begin, filter, filter_end? Sure. It's not safe to open file descriptors in the main body (outside of the callback functions) of the perl filter because these are only called once and will get closed (by subsequent slaves calling close(2) post fork)? Correct (for embedded perl, which everyone should be using anyway.) Equally it's also not safe to open file descriptors in the other pre-body filter callback functions (such as filter_sender) because it cannot be gauranteed that the same slave will process the body (in the same way global vars cannot be used in these)? Well, you can open file descriptors in the pre-body callbacks as long as you use them and close them in the same callback. However, if you leave a file descriptor open in filter_sender, you can't predict who will see it next. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] MIMEDefang 2.48 is available
Chris, * embperl.c: Detect if user opens file descriptors inside his/her filter. If so, log a loud and nasty warning that such code should be moved to filter_initialize. Why is it a problem to do this outside of filter_initialize? The design of MIMEDefang is such that you cannot guarantee that the slave which started processing your message is the same as the slave which finishes the processing, as each part of the SMTP process could be passed to a different slave. If you have enabled checking at all stages, there could be different slaves for filter_relay, filter_sender, filter_recipient, one filter() per entity, and then also a filter_end call. As slaves are reaped when they have processed a configured number of requests to ensure memory usage is limited, your slave could terminate after the first part of the message, and a different slave could take over. If the file descriptor use is completely local to the procedure (i.e. you open a file, write to it, then close it), then your use is probably safe (subject to locking race conditions). If you open it in filter_sender, then attempt to read from it in filter_recipient, then you are digging a very large hole for yourself - in many cases, it will work, especially on lightly loaded systems, but you will then find it failing with obscure side effects or untraceable problems when the load rises. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.48 is available
* embperl.c: Detect if user opens file descriptors inside his/her filter. If so, log a loud and nasty warning that such code should be moved to filter_initialize. Why is it a problem to do this outside of filter_initialize? I guess this would affect database failover reconnection code [outside of filter_initialize] upon detection of connection errors? Chris __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] MIMEDefang 2.48 is available
On Mon, 1 Nov 2004, Chris Masters wrote: * embperl.c: Detect if user opens file descriptors inside his/her filter. If so, log a loud and nasty warning that such code should be moved to filter_initialize. Why is it a problem to do this outside of filter_initialize? Because after we fork a child, we close() all unneeded file descriptors (see mimedefang-multiplexor.c, around line 2193. This will most likely close the file descriptor out from under Perl -- that is, Perl will think the descriptor is open, but the C code will have closed it. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
