pthreads at bmcweb

[Ed Tanous]

Another option might be something like c-ares, the description of which is:

c-ares... is intended for applications which need to perform DNS
queries without blocking, or need to perform multiple DNS queries in
parallel. The primary examples of such applications are servers which
communicate with multiple clients and programs with graphical user
interfaces.


Sounds like exactly our problem statement, so it might be worth a look
to see how much binary size it adds.

On Wed, Jan 6, 2021 at 12:02 AM Sunitha Harish
<sunithaharish04 at gmail.com> wrote:
>
> Hi team,
>
> Reference commit https://gerrit.openbmc-project.xyz/c/openbmc/bmcweb/+/31735 :
>
> In order to handle the multiple push-style event subscribers, bmc needs to support the async resolution of the subscribers address. The async_resolve() API crashes if there is no thread support in the binary.
>
> I created a bmcweb binary patch by pulling this commit and including the pthread. This works fine for the use-cases, but increased the bmcweb binary size by 220KB.
>
> Ed's suggestion is not to use the pthreads, instead implement alternatives to do the same job, so that the binary size is kept minimum. He mentioned: "Considering that's a ~30% increase in binary size to support one line off code, and most systems are already at their binary size limit, no, that's not going to be acceptable. We can either patch boost to use this https://man7.org/linux/man-pages/man3/getaddrinfo_a.3.html or we could build our own resolver type that calls that underneath. This was based on a quick lookthrough of solutions in Google. I'm open to other ideas here".
>
> I am looking for the community views about the increased bmcweb binary size v/s having a custom implementation for asyc_resolve. Please share your views & ideas to get to the best solution.
>
>
> Thanks & regards,
> Sunitha
>
>