[upnp-sdk-dev] Patches: Remove ithread.h header and change users over to pthreads

[Hartwig D. <har...@gm...>]

Hi,

as the patches somehow disappeared, probably because anonymous upload of
patches is not allowed, I have re-uploaded the changes required for getting
rid of ithreads.
This time, I have split this change up into 3 patches this time. The first =
2
patches change users of the ithread header from the threadutils and the upn=
p
subdirectory to directly use pthreads, and the last one actually removes
this header.

Thus, the maintainers have the choice to actually keep around this header
file, so external applications using it can continue so for a while, in
order not to suddenly break the API (no idea whether the API of libupnp is
considered stable already).

Any opinions apart from Mike on this subject?


Also, a few replies to Mike's statements

2006/4/26, qx...@gm... <qx...@gm...>:

> The point is, that there must be a reson for the Intel developers to do i=
t
>
> in that way. What else than the preparation for porting it to other
> systems should it be?

This is wild guessing, but maybe Intel did have pthreads implementations fo=
r
other platforms such as windows or vxworks, but decided to not release them=
?
Still, I do think they should have made it a separate libpthread then.


On the other hand: what do we win with that change? I think nothing, the
> code will not become smaller because these defines are replaced by the
> preprocessor completely.

Well, I believe getting rid of code obfuscation is always worth it. Also,
code does bit-rot if it is unmaintained.
Examples of this are already present, as ithread.h currently contains broke=
n
defines (ithread_mutexattr_setkind_np vs. pthread_mutexattr_settype
available on my SUSE Linux 9.3), and does miss functionality available in m=
y
current pthreads package (function pthread_testcancel, macro
PTHREAD_MUTEX_INITIALIZER).

Beside of that you pointed to an other big problem with that patch: it is
> a user-visible API change that is not good for compatibility.

The problem of a user-visible API change can be aleviatedby carrying around
the ithread.h file for a while, possibly adding a big warning that it is
going to be removed in the future.


Hartwig