On Tuesday 27 May 2008 19:07:25 Michael Gogins wrote:
> It turns out that the Csound API defines a thread object as void * (4
> bytes), but the Windows implementation of the pthread API defines a thread
> object as
>
> typedef struct {
>     void * p;                   /* Pointer to actual object */
>     unsigned int x;             /* Extra information - reuse count etc */
> } ptw32_handle_t;
>
> which has a different size (8 bytes).
>
> Consequently, changing all Csound threads to pthreads would involve a
> breaking change (although a minor one) in the Csound API. The threading
> calls would be changed to return some opaque type 8 bytes in size, such as
> "long long."

Or you could return a pointer to a ptw32_handle_t, casted to void*? I think 
this way you keep source and binary compatibility (unless an application is 
doing stuff it shouldn't).

>
> Please indicate your preference for one of the following options, or
> suggest another if you like:
>
> 1. Perform the API change. "long long" works for both MinGW and MSVC, and
> probably works on all Csound platforms, but a union with a dummy name and
> the actual type would be future proof.

How do you know that ptw32_handle_t won't change in the future? Actually, that 
would make the csound ABI dependent on the pthread ABI. Returning a pointer 
should keep compatibility AFAICS.

>
> 2. Remove the Csound threading API altogether, and let users use the
> pthread API in its place.

This sounds reasonable. I fail to see why should csound provide a threading 
API. This would break API and ABI, though (and require changes to at least 
tclcsound, the fltk gui and csoundVST, according to a quick grep).


-- 
Felipe Sateler