I wonder whether the (not interrupts-enabled) is a good idea: I expect that if you're handling huge strings, interactivity of other threads will suffer.
(Hm, thinking about it: for huge strings (those bigger than a cpu cache will hold), it could be worthwhile to run the comparisons and hashing activities in a set of separate OS threads; then you could not only run blocking code (even handcoded C code or just memcmp for comparisons, and e.g. lookup3.c by Bob Jenkins for hashing), but also make use of multiple processors.
I'd offer to implement it for you using pthreads or with a thread abstraction layer if someone points out a good portable one (but it has to offer a way to hook into the Gambit scheduler--using pipes for synchronization is the easy way but rather posixish); I'm not sure whether that should be in the Gambit core, though, it could live in modules (yeah which module system I hear you ask; I'd do in mine first just because I've got lookup3 and posix bindings already working), but maybe it would even make sense to put a system threading engine for lowlevel work into Gambit already, it could prove useful for more things than just that?)
Christian.