Bart Smaalders writes: > 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?
Which, of course, has run many folks into trouble and thus has setuid safeguards as well as frequent "don't do this" warnings. > Or change > the default library search order w/ LD_CONFIG? Same issue. > Or to select the number > of processors used w/ NCPU? That seems a bit different, as it doesn't actually choose an different implementation. > > 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 see. If the person integrating this library is adamant that preserving this "feature" really is the right thing to do on Solaris, I guess I'll back down. I'm not prepared to derail over it. It just doesn't seem wise to me. > > 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. OK ... so that's not part of this project, right? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
