[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Something to consider for future



On Sep 7, 2010, at 9:35 AM, Nick Mathewson wrote:

> Hi, Ralph!
> 
> On Tue, Sep 7, 2010 at 11:04 AM, Ralph Castain <rhc@xxxxxxxxxxxx> wrote:
> [...]
>> (b) we need to modify it somewhat to get things working correctly across the broad range of our installed base.
> 
> Any chances of getting the patches here upstreamed?  "Working
> correctly across a broad install base" sounds like a feature worth
> merging into the main distribution. ;)

I'm still working through what was done, but will certainly pass them along as I decipher them. From what I see, they are mostly centered around things like epoll not working quite the way you expected on certain platforms (so we have to ensure that mode doesn't get used there), etc. I don't see where people tried to solve the problem, but more tried to ensure it was avoided. :-/

> 
>> It is my understanding that quite a few software packages also embed libevent in their distributions, so this is a fairly common problem. It would make life much easier, therefore, if you only declared the true public APIs as public symbols, defining all internal-only functions as "static".
> 
> Pretty much every symbol that's used only in a single module *is*
> declared static right now.  (If we missed some, that's worth fixing:
> just send in a patch.)  The remaining non-static symbols are ones
> shared between modules, and of course C doesn't let you make those
> static.  The right solution here is probably to manually tell the
> linker about what symbols to export and what symbols not to export.
> On windows, this is the dllexport/dllimport stuff stuff.  With gcc4 on
> other platforms, this is the __attribute__((visibility(...))) stuff.
> ( http://gcc.gnu.org/wiki/Visibility )
> 
> I'd like to move this way in Libevent 2.1, but I'm not sure on the
> timeframe, since it's a fair amount of work.  If somebody commits to
> writing up and testing the code here, that'll improve the odds of it
> getting done.

I agree - it's basically a visibility issue. I could certainly test for you, and can try to get to the coding part as time permits.

Cheers
Ralph

> 
> peace,
> -- 
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.