threadutil library has no public headers

[pupnp]

threadutil library has no public headers

[ffontaine]

Indeed, ithread.h is now the (only) public header of threadutil in version 1.8.
I completely agree that ithread.h is a simple wrapper to pthread and does not have any dependency to threadutil.
However, the "standard" pupnp library (in version 1.6.x) shares 4 other headers (TimerThread.h, ...)

My personal opinion is that we should not forcefully compile threadutil as a static library. Building static or dynamic version of libraries should be controlled through the --enable-static, --disable-static, --enable-shared or --disable-shared configure options. The decision to make a dynamic or a static version should be made by the end user. However, I'm in favor of completely removing the threadutil library and move all the related code to libupnp.

@mrjimenez, do you have an opinion on this one? I saw that you removed the "standard" threadutil headers in ee9f83c. Why did you keep ithread? Do you think we should completely remove threadutil?

[mrjimenez]

Hi James and Fabrice,

The changeset you mention was in line with the 1.8.x philosophy of not exposing internal data structures, so that the developers could change internal stuff that did not change the API and at the same time this would not require a new library version due to compatibility breakage.

The header ithread.h is just a wrapper that did not expose anything, so it has been kept. The original idea behind this separate library is from a time before I was in the project, and if I recall correctly, the explanation was that some embedded systems could have their own "economic" implementation of a thread layer.

Since we are moving to 1.8, I see no need to keep this, we just leave that in 1.6 and move on. I am in favor of including the code in libupnp and not link it separately.

Regards,
Marcelo.

[ffontaine]

Thanks for your feedback Marcelo. I made a patch with this change. It works well on Linux and I will send a PR.
However, there is a lot of references to threadutil in the build directory. All those references are related to Visual Studio files in version 8 to 10. As I'm not an expert on this part (and so unable to test any modification on these files), my suggestion would be to push this commit (after your review) and let anyone that is interested with Windows do the update.

[mrjimenez]

100% agree with you.