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.

Reply via email to