On 2012-12-11 3:31 AM, Lyndon Nerenberg wrote: > On 2012-12-10, at 19:06 PM, David Levine wrote: > >> Would it make sense to toss it all and use mmap()? > That would kill the Plan 9 port.
i'm touched by the idea of memory mapping mail files. makes one think of TOPS20. however, no. the API takes a FILE * as its final argument. mmap needs a file descriptor. if we're going to touch all of m_getfld()'s callers to get them to send a file descriptor instead, we should get more payback than merely avoiding stdio. we need a way way way better way to talk to the message interface. in fact we need a message interface. and for all i know some of m_getfld's callers are passing in a socket or a pipe sometimes. i remember looking at the MH source code after i'd been using it about a year. so, maybe 1986? anyway i saw that there was no middleware layer, no way to write my own C utility that could benefit from MH's libraries and do interesting high level things with mail messages. it was a major letdown, since the command line was so well designed that it made me expect a "libmh.a" that i could link against, with functions like "mh_openfolder" and "mh_openmessage". instead i found m_getfld. WHAT a letdown. /* * packed maildrop - only take up to the (possible) * start of the next message. This "matchc" should * probably be a Boyer-Moore matcher for non-vaxen, * particularly since we have the alignment table * all built for the end-of-buffer test (next). * But our vax timings indicate that the "matchc" * instruction is 50% faster than a carefully coded * B.M. matcher for most strings. (So much for elegant * algorithms vs. brute force.) Since I (currently) * run MH on a vax, we use the matchc instruction. --vj */ paul _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers