After starting this work, and reading Steven Yi's emails, I realized that 
the Csound API currently uses both pointers and values for the threading 
calls.

Therefore, there is no reason not to keep the present void * signatures and 
simply pass the pthread_t thread object as a pointer as well, instead of a 
value as it currently is.

The pattern in the rest of the Csound threading API is to malloc memory for 
objects in the creator calls and free it in the destructor calls. This can 
obviously be done for the csoundThreadCreate and csoundThreadDestroy calls 
as well.

This is what I am doing.

Regards,
Mike
----- Original Message ----- 
From: "Michael Gogins" 
To: "Developer discussions" 
Sent: Wednesday, May 28, 2008 8:10 PM
Subject: Re: [Cs-dev] Threading again


> 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
> 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