in reply to Redirect data and Filehandle manipulation (STDIN x Disk IO)

You can't seek on a pipe. You may be able to seek (though I've not tried) on a redirection, e.g., "./filter.pl < filter.pl". But that's not what you want.

What you want to do is read everything into memory, and spit it out to the multiple destinations. Well, not quite - some emails can get quite large.

Closer is to buffer the header. Once you've determined if you're doing to do something with it based on the $dfrom, then you can loop through the header before going through stdin for data on your next time through the email.

More realistically, copy the whole thing to a temp file, and use that. You can seek all you want on a temp file.

  • Comment on Re: Recirect data and Filehandle manipulation (STDIN x Disk IO)

Replies are listed 'Best First'.
Re^2: Redirect data and Filehandle manipulation (STDIN x Disk IO)
by mda2 (Hermit) on Jul 01, 2005 at 15:13 UTC
    I really need to work without write temp file, to improve performance on postfix smtp servers.

    After your response I found references for "< redirection" ("opens the file for input, default unit 0"), and confirm with lsof command:

    script < input & # lsof -p PID COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME ... cut ... perl 20316 root 0r REG 8,2 43151 1564123 /root/av/mail.e +xploits perl 20316 root 1u CHR 136,2 4 /dev/pts/2 perl 20316 root 2u CHR 136,2 4 /dev/pts/2

    Thank's for your response!

    --
    Marco Antonio
    Rio-PM

      To be honest, I would still use a temp file. And then, because this is perl, you could change it from an IO::File to an IO::Scalar later and compare if you're really saving any clock time. I'm betting it's not going to be significant on most modern hardware and OS. HD speeds continue to improve, as do the caching algorithms of the OS.

      This smells of premature optimisation to me.

        I'm using 5 dell servers (2 Xeon 3.2, 2GB ram, hds scsi, inet gbit), on normal traffic 1 G messages daily, but frequently we are target from spams/worms, and content filter is my task to improve performace...

        With normal usage of STDIN or temp file is equal, on hush hours it's the disk io is problem...

        I'm trying it before propose changes on content filter method...

        Perhaps this is exaggerates, but the profit called me attention. Other plataform changes are possible... :(

        --
        Marco Antonio
        Rio-PM

        Really... I lost us time... it's don't functional with postfix content-filter (node updated).
        I getting all content into a scalar, considering memory/disk io speed, max message size and process limits (to don't use swap).

        Thank's by your attemption!

        --
        Marco Antonio
        Rio-PM