The pthreads API signatures are identical to the programmer. The actual 
types (pthread_t etc.) are not identical. And they are 8 bytes on Windows, 4 
on Linux; thus they cannot be type cast to void *.

Regards,
Mike

----- Original Message ----- 
From: "Steven Yi" 
To: "Michael Gogins" ; "Developer discussions" 

Sent: Wednesday, May 28, 2008 6:29 PM
Subject: Re: [Cs-dev] Threading again


> Aren't the Csound API thread handling functions dereferencing the
> pointer to whatever they need before passing on to Windows or pthreads
> API?  So the "pthread" enabled API will cast and then dereference the
> pointer before passing to pthreads.  If we use pthreads, shouldn't
> just be able to reuse the Linux implementation of the Csound API
> methods related to threading?  Or is pthreads different on Windows
> than elsewhere?  (which would be really strange to make it
> different...)
>
> On Wed, May 28, 2008 at 2:02 PM, Michael Gogins  
> wrote:
>> It doesn't work so well because ptw32_hand_t is treated by the Windows 
>> pthread API as a value type, not a pointer.
>>
>> Regards,
>> Mike
>>
>> -----Original Message-----
>>>From: Steven Yi 
>>>Sent: May 28, 2008 4:02 PM
>>>To: Developer discussions 
>>>Subject: Re: [Cs-dev] Threading again
>>>
>>>I was going to mention casting the void * to ptw32_hand_t *.  I
>>>thought we might be doing that for the native windows threading stuff
>>>now.  Anyways, doing that should maintain binary compatibility which I
>>>think would be good.
>>>
>>>On Tue, May 27, 2008 at 5:00 PM, Felipe Sateler  
>>>wrote:
>>>> 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
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>
>>>-------------------------------------------------------------------------
>>>This SF.net email is sponsored by: Microsoft
>>>Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>_______________________________________________
>>>Csound-devel mailing list
>>>Csound-devel@lists.sourceforge.net
>>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net