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

[<qx...@gm...>]

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

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.

What do we lose? In my opinion a (probably small) piece of compatibility.  
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.

Mike



On Wed, 26 Apr 2006 16:45:05 +0200, Hartwig Deneke  
<har...@gm...> wrote:

> 2006/4/26, qxc@ <qx...@gm...>...
>>
>> there is one big problem with this change: the current variant offers an
>> easy way to port the library to other operation systems that do NOT use
>> the
>> pthreads-thingy (like Windows).
>>
>> Currently the adaption has to be done in ithreads.h only, using this
>> change
>> developers have to modify the code everywhere.
>>
> Hi,
>
> I do not agree with this argument. libupnp currently depends on posix
> threads functionality, renaming functions from pthread_xxx to ithread_xxx
> does nothing to change this. No additional functionality is provided by  
> the
> ithread header!! Hence, the fact that libupnp requires posix threads (and
> uses its data-structures) is hidden, which is IMHO a bad thing. If  
> libupnp
> was using actually using a portable threads library, it would be a
> completely different story.
>
> Once somebody decides to port libupnp to a platform without posix  
> threads,
> the functionality of the required subset of pthreads has to be provided  
> for
> that platform. Why not implement it as a separate library, preferrably
> called libpthread and providing a header pthread.h (it could still be
> distributed with the libupnp source code, but at least for me, this seems
> like an independent task)?  BTW, there is a pthread library for win32,  
> see
> http://sourceware.org/pthreads-win32/, so no need to worry about windows.
>
> BTW, there is something else to consider about these patches: projects  
> using
> libupnp might have to be changed, if they use ithread.h, thus this is a
> user-visible API change (checked with gmediaserver, which does use this
> header, if only in a few places).
>
> Hartwig