I/O Multiplexing
Dear DDJ,
I found Ian Barile's article "I/O Multiplexing & Scalable Sockets" (DDJ, February 2004) of grand proportions to be quite enlightening. I would, however, like to comment a bit on his mention of existing implementations. Ian posits that there are few I/O multiplexing implementations out there (which is true). However, I must point out that FreeBSD has an (quite powerful) alternative to traditional select/pollkevent/kqueue. Besides being far more efficient than select/poll, it also acts upon a larger set of system objects than just file descriptors. For example, predefined system filters make it possible to monitor for: vnode events (UFS filesystems only), socket/file/pipe/BPF descriptor events, network device events, timer events, asynchronous I/O (AIO) events, and process events. The API provides not only an adequate interface for the scalable I/O multiplexing that Ian seeks, but it also provides a means for monitoring for events generically.
Anthony Schneider
anthony@x-anthony.com
Who's On First Redux
Dear DDJ,
In regards, to Ron Wolf's "Letter" and Ed Nisley's response concerning the Atanasoff versus Univac debate (DDJ, March 2004), a new book entitled Who Invented the Computer?: The Legal Battle That Changed Computing History, by Alice R. Burks (Prometheus Books, 2003) adds more weight on Atanasoff's side. A grain of salt: Consider that Eckert and Mauchly stood to lose large amounts of money if their claims were invalidated.
Also in the March issue, the title of the article "Fostering Little Languages" by John Clements et al., rang a bell. "Little Languages" is a chapter heading in the book The AWK Programming Language, by Aho, Weinberger, and Kernighan. Their examples include designs for translators for really little languages. Examples include an assembler and interpreter, a graphing language, a language to describe sort commands in English, RP and infix calculators, and simple parsers. The assembler example has been adapted to real-world code generation for special-purpose processors built in programmable-logic arrays.
Bill Hickok
hickok@eznet.net
Doubling Down On Double Dispatch
Dear DDJ,
In his letter, "Double Dispatch Again Revisited" (DDJ, March 2004), Wolfgang Stephan comes full circle in the quest for an elegant solution to the double dispatch problem, which would allow for inheritance. Wolfgang's proposed solution appears identical to Scott Meyers's second attempt, quickly discarded, to address this problem in Item 31 of More Effective C++: 35 New Ways to Improve Your Programs and Designs (Addison-Wesley, 1996). The "fatal flaw" with this approach, according to Meyers, is that every existing GameObject-derived class must be modified whenever a new GameObject-derived class is added to the class hierarchy. His goal was to make the solution extensible without requiring changing, much less recompiling every existing class when a new derived class is added. Meyers's finally arrived at a solution both elegant and flawed. His idea was to create a map that associates pairs of class names with function pointers. The elegance of this approach was that it made use of Run-Time Type Identification (RTTI) to create the key strings, eliminating the need to add any extra members to the classes in the hierarchy in order to manage them. The flaw, of course is that type names in the map had to match the class names exactly, short circuiting inheritance.
Nat Goodspeed attempted in "Double Dispatch Revisited" (DDJ, January 2004) to address this new problem by replacing the std::pair<std::string,std::string> object that Meyers used as the key in his map with a functor class. I'm not going to completely summarize the article here, since clearly Wolfgang has taken the time to read it. But perhaps Wolfgang should (re)read the original item in Meyers's book, which inspired Nat's article.
David M. Miller
dmmiller@acm.org
Java 2D & Web Pages
Dear DDJ,
Late last year, I was contacted by Dav Coleman asking if I could help him with some code that appeared in my article "Java 2D & Web Pages" (DDJ, October 2003). The next time I heard from him, he had built an XMLRPC based on my code, turned it into a web service, and was using it on his site. Later on, somebody told me that I showed up on SourceForge. Turns out, Dav turned the whole thing into an open-source project. If readers want a peek at what he did, they can go to http://akuaku.org/archives/001138.shtml.
Paul Tremblett
ptremblett@audioaudit.com
Tech Support
Dear DDJ,
In his editorial "Small Is Beautiful" (DDJ, March 2004), Jonathan Erickson writes "Getting up early is a small price to pay to talk to a qualified engineer." I disagree. Dell (and other companies) owe their customers a qualified support technician no matter what time they call, and no matter where the call is routed. If they can't do that, the customers can, should, and eventually will find another company with which to do business.
Steve Greenland
steveg@moregruel.net
Porting Small-C
Dear DDJ,
Kudos to Pete Gray for his article "Porting Small-C" (DDJ, March 2004). Reference is made to "versions for the original 8086," but in fact the original Small-C Handbook, by James E Hendrix, which I have now on my desk, was written using the 8-bit 8080 processor. The software ran under the CP/M operating system. Reference is made to "the 8086 is an 8-bit microprocessor." The 8086 was a 16-bit microprocessor. Instructions, registers, and data transfer were all 16 bits. Perhaps part of the confusion arises from the fact that the particular variant used in the original IBM PCthe 8088had an 8-bit data path. This did not affect the program, however, only slowing data fetch (two fetches for 16 bits instead of one) and was invisible to programmers who wrote for 16-bit computers. Finally, in regards to Pete's complaint that "documentation for the assembly language and 8086 processor is difficult to come by": The original reference manuals were available on the Intel web site until recently, and many books were written on the assembly language, some still current; for instance, Assembly Language for Intel-Based Computers, by Kip Irvine (Prentice Hall, 2002).
Harvey Nice
harvey@cti.depaul.edu
DDJ