praks wrote: > James Carlson wrote: > > 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. > > > > Yes, we would like to keep this feature. > > > > >>> 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? > > > > Yes, this will not be included in the libevent > library that gets > delivered in Solaris. > > -Prakash.
Ok, I can certainly see that there might be security, performance, or design issues against a builtin http server. But I would also suppose there must be _some_ freeware out there that depends on it. Are we aware of what that might be, and whether it can work without it? I mean, Doing The Right Thing is important, but being aware of the consequences isn't a bad idea either... This message posted from opensolaris.org
