James Carlson wrote: > Bart Smaalders writes: >> It is possible to disable support for any of these event notification >> mechanism by setting the relevant environment variable. This is >> documented in the man page. > > That's just frightening. This appears to mean that the internal > design of the library can (in effect) be altered by the end user at > run time. >
You mean like LD_LIBRARY_PATH to select an alternate malloc implementation, interpose audit libraries, and the like? Or change the default library search order w/ LD_CONFIG? Or to select the number of processors used w/ NCPU? > Any clue why this is a reasonable thing to include in this delivery? > Is there any advantage to allowing the end user of an application > linked to libevent to "tweak" the underlying mechanism? There's a long history in all sorts of places of modifying application behavior with environment variables. The selection of dispatching mechanism used internally inside libevent seems to be just yet another choice. Given the history of bugs in all the mechanisms available - /dev/poll, kqueues, epoll, etc, providing a mechanism to select a possibly less broken implementation doesn't seem that unusual. > > I can understand perhaps it when compiled with -DDEBUG, but it seems > strange and potentially hazardous otherwise. > >> In addition, libevent implements interfaces that provide additional >> functionality for embedding an event driven http server and buffered > > An http server? > As far as I know, this was removed from all but the man page. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
