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