[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.