[243] in Zephyr_Bugs
[eichin@ATHENA.MIT.EDU: Re: suggested change to zmailnotify]
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Tue Feb 19 21:14:53 1991
Date: Tue, 19 Feb 91 21:14:36 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
To: bug-zephyr@ATHENA.MIT.EDU
----- Forwarded message
Date: Thu, 14 Feb 91 04:44:44 -0500
From: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
To: Mark W. Eichin <eichin@ATHENA.MIT.EDU>
Cc: bugs@ATHENA.MIT.EDU
In-Reply-To: [6482]
Subject: Re: suggested change to zmailnotify
I've implemented some of the changes I suggested back in November. I tested
them by mailing myself a 300K message consisting of two copies of
/etc/termcap; on a microvax, zmailnotify finished (including sending the four
Zephyr notifications) in under 30 seconds realtime.
>> 1) changing "multiline" to detect a blank line (as end of
>>headers) and flush the rest of output, returning DONE
>> 3) on general principles, call pop_command("QUIT") and
>>pop_close() *before* calling mail_notify, so that the mailbox doesn't
The changes are about as clean as the existing code :-) The change to
multiline doesn't really belong there, but doing it "right" would require
restructuring all of zmailnotify - which is already using code stolen from
other places that isn't all that appropriate to begin with. Once it finds a
blank line, instead of returning it as a normal line, it loops until it finds
a "." on a line by itself, then returns DONE to indicate that the message is
done.
Changing mbx_write to use a large buffer instead of doing realloc
does not seem to speed things up; presumably the code is I/O bound at this
point (^T indicates that it is "waiting" most of the time on the long
message... in fact, in 30 seconds of real time it only uses 4 user and 1.5
system CPU seconds.) I did implement a better mbx_write, which you'll find in
/mit/eichin/projects/zephyr/zmailnotify.c but it will be a little tricky to
audit and while it does make the code more robust (the original never even
checked the return values of malloc or realloc, tsk tsk...) and it probably
would have made the original version faster (since it wouldn't have
realloc'ed nearly as often) the need to realloc large amounts of data is
eliminated by suggestion 1 above.
rcsdiff's follow.
_Mark_ <eichin@athena.mit.edu>
MIT Student Information Processing Board
RCS file: RCS/zmailnotify.c,v
retrieving revision 1.10
diff -c -r1.10 zmailnotify.c
*** /tmp/,RCSt1008396 Thu Feb 14 03:51:57 1991
--- zmailnotify.c Thu Feb 14 03:45:08 1991
***************
*** 192,197 ****
--- 192,201 ----
!strcmp(maillist[nmsgs-i].subj,mymail.subj)))
break;
}
+
+ (void) pop_command("QUIT");
+ pop_close();
+
i++;
for (;i<=nmsgs;i++)
mail_notify(&maillist[nmsgs-i]);
***************
*** 209,216 ****
maillist[nmsgs-i].subj);
(void) fclose(lock);
- (void) pop_command("QUIT");
- pop_close();
exit(0);
}
--- 213,218 ----
***************
*** 531,536 ****
--- 533,544 ----
} else {
(void) strcpy(buf, buf+1);
}
+ } else if (*buf == '\0') {
+ /* suck up all future lines, since this is after all only for headers */
+ while(! ((buf[0]=='.') && (buf[1] == '\0')) ) {
+ if (getline(buf, n, f) != OK) return (NOTOK);
+ }
+ return DONE;
}
return(OK);
}
----- End of forwarded message
