Bug 5521 - Avoiding one copy of mail during Mail::SpamAssassin::check
Summary: Avoiding one copy of mail during Mail::SpamAssassin::check
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Documentation (show other bugs)
Version: 3.2.1
Hardware: All All
: P5 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-17 14:59 UTC by Mark Martinec
Modified: 2007-11-23 20:26 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Martinec 2007-06-17 14:59:40 UTC
I'm looking for ways of minimizing in-memory copies of a mail message
when an application program (like spamd or amavisd) calls SA.
It turns out the topic can have deep implications and is quite broad,
so I'll keep the question for this problem report very simple, and
leave the rest to a potential new p-r.

The normal API goes like this:
  $spamtest = Mail::SpamAssassin->new();
  $mail = $spamtest->parse($message);
  $status = $spamtest->check($mail);

On a call to parse() the $message may be a single multiline string,
an array reference, or a file handle. When deciding which one to
use, an answer to the following question would be valuable.

So the question is: when passing a message to parse() as an arrayref
(and noticing that the current code makes a copy of it), is it safe
for the called to discard its array _before_ calling check() ?

Currently this is not documented, so one interpretation is that
a door is intended to be left pen for a possible future change,
which might let SA routines to work directly on the passed array,
instead of on its copy.

If this is not the case and in fact it is allowed to ditch the array
right after calling parse(), it would be nice if this were documented
explicitly (a single statement would suffice in the man page).