Here's how I implemented set intersection in Perl today:
When writing a library, sometimes it is necessary to suppress SIGPIPE that is generated by OS when the thread tries to write to a pipe with no reader on the other end. Surprisingly, this is not as straightforward as one might think. I myself implemented it twice (in Cache::Memcached::Fast prior to 0.18, and in XProbes prior to 0.4), and both times did it wrongly (it's worth noting that the bug couldn't affect applications that use these libraries, unless they do sophisticated handling of SIGPIPE themselves in a multi-threaded context, which is a very rare case). Considering the problem once more, I finally came to the correct solution.
In memcached 1.2.5 text protocol there was introduced a noreply command modifier, that allows the client to instruct the server to not send the reply for a given command. When used, it greatly reduces request latency. Many memcached clients has supported it since then, yet from time to time there are posts in memcached mailing list (coming mostly from one person) that proclaim that noreply is inherently broken, and is "fixed" by replacing it with "quiet" commands in binary protocol. Surprisingly, some users who are lazy to think themselves do buy it. Since it was me who added noreply to memcached (and the idea was by Michael Monashev), let me explain why noreply is a good thing, and how it differs from "quiet" commands.