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