pthreads at bmcweb

[Milton Miller II]

On Jan 6, 2021 Sunitha Harish 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.

I agree with Ed that adding pthreads is a step that should be taken 
with a lot of caution.   In addition to the binary size, a threaded 
application also adds security audit concerns.

A quick search with the query of "dns lookup library embedded" found 
a possible library with a probably compatible license (although last 
update was 4 years ago), and the second link was a survey of other 
client and server packages that could be investigated.

My personal opinion only.

milton