Hi All,

One of the things that has been nagging me a bit is that we made a
decision a while back (I think I proposed it) to accept use of
pthreads as the base for all platforms. I think this was around the
time of Android/iOS but I am not certain.  As a result, we removed
some older code (i.e., Mac OS9) but we also have a situation now where
some files use pthread.h directly and others use csound's threading
functions.

I'd like to go back now to using just csound's threading functions and
remove use of pthreads throughout the code base.  The reasons for this
are as follows:

1. Some platforms do not have pthreads (i.e., Emscripten) and the
hacks (i.e., #ifdef EMSCRIPTEN) that were added aren't great.  We may
also want non-threaded builds as an option, and just using our
threading functions gives us flexibility here.

2. Pthreads has been a little problematic on Windows.  In the past,
when we dynamically linked to them , it caused problems when loading
in DAWs where it appeared to conflict with other pthreads
implementations.  We then moved to static-linking.  I think that using
Windows' thread functions should be better when on Windows for
performance, and it would also remove a dependency.  This in turn
helps to simplify another issue:

3. I've been looking at getting  Csound buildling with Visual Studio.
My plan of attack is to follow something along the lines of what I did
for XCode, which is to have a script that will download all
dependencies then run CMake pointing at those dependencies.  The idea
is to have an easily reproducible build (and of course, to allow using
VS).  Pthreads has proven to be somewhat of a pain to deal with, and I
think it'd get more complicated to get to work with both x86 and x64.
This part of the VS setup would be simplified if we got rid of
pthreads.

Comments?

Thanks!

I am neutral with respect to this. It seems unnecessary to me, as I
have never had any problems using the extant open source prebuilt
pthreads libraries, but if you get it to work and it saves you or
other people problems then it's fine with me.

We do of course have to make the Csound threading API functions
members of the CSOUND structure and available for plugins to call, if
they are not already (I think they are, but we need to be sure).

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Dec 6, 2016 at 11:47 AM, Rory Walsh  wrote:
> You have my blessing ;) I have been bitten by problem 2 on your list several
> times, but I have to admit to having limited knowledge of the consequences
> of changing back. I would also love to see a Visual Studio build, so if this
> helps, then once again you have my blessing.
>
> On 6 December 2016 at 16:41, Steven Yi  wrote:
>>
>> Hi All,
>>
>> One of the things that has been nagging me a bit is that we made a
>> decision a while back (I think I proposed it) to accept use of
>> pthreads as the base for all platforms. I think this was around the
>> time of Android/iOS but I am not certain.  As a result, we removed
>> some older code (i.e., Mac OS9) but we also have a situation now where
>> some files use pthread.h directly and others use csound's threading
>> functions.
>>
>> I'd like to go back now to using just csound's threading functions and
>> remove use of pthreads throughout the code base.  The reasons for this
>> are as follows:
>>
>> 1. Some platforms do not have pthreads (i.e., Emscripten) and the
>> hacks (i.e., #ifdef EMSCRIPTEN) that were added aren't great.  We may
>> also want non-threaded builds as an option, and just using our
>> threading functions gives us flexibility here.
>>
>> 2. Pthreads has been a little problematic on Windows.  In the past,
>> when we dynamically linked to them , it caused problems when loading
>> in DAWs where it appeared to conflict with other pthreads
>> implementations.  We then moved to static-linking.  I think that using
>> Windows' thread functions should be better when on Windows for
>> performance, and it would also remove a dependency.  This in turn
>> helps to simplify another issue:
>>
>> 3. I've been looking at getting  Csound buildling with Visual Studio.
>> My plan of attack is to follow something along the lines of what I did
>> for XCode, which is to have a script that will download all
>> dependencies then run CMake pointing at those dependencies.  The idea
>> is to have an easily reproducible build (and of course, to allow using
>> VS).  Pthreads has proven to be somewhat of a pain to deal with, and I
>> think it'd get more complicated to get to work with both x86 and x64.
>> This part of the VS setup would be simplified if we got rid of
>> pthreads.
>>
>> Comments?
>>
>> Thanks!
>> steven
>

Another thing to note having a non-threaded build may help in
addressing issues with Bela (http://bela.io/) that we were looking at
in Maynooth.  That's related to the Emscripten build as well, but it
doesn't make sense to defined EMSCRIPTEN to build for Bela.

On Tue, Dec 6, 2016 at 12:21 PM, Michael Gogins
 wrote:
> I am neutral with respect to this. It seems unnecessary to me, as I
> have never had any problems using the extant open source prebuilt
> pthreads libraries, but if you get it to work and it saves you or
> other people problems then it's fine with me.
>
> We do of course have to make the Csound threading API functions
> members of the CSOUND structure and available for plugins to call, if
> they are not already (I think they are, but we need to be sure).
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Dec 6, 2016 at 11:47 AM, Rory Walsh  wrote:
>> You have my blessing ;) I have been bitten by problem 2 on your list several
>> times, but I have to admit to having limited knowledge of the consequences
>> of changing back. I would also love to see a Visual Studio build, so if this
>> helps, then once again you have my blessing.
>>
>> On 6 December 2016 at 16:41, Steven Yi  wrote:
>>>
>>> Hi All,
>>>
>>> One of the things that has been nagging me a bit is that we made a
>>> decision a while back (I think I proposed it) to accept use of
>>> pthreads as the base for all platforms. I think this was around the
>>> time of Android/iOS but I am not certain.  As a result, we removed
>>> some older code (i.e., Mac OS9) but we also have a situation now where
>>> some files use pthread.h directly and others use csound's threading
>>> functions.
>>>
>>> I'd like to go back now to using just csound's threading functions and
>>> remove use of pthreads throughout the code base.  The reasons for this
>>> are as follows:
>>>
>>> 1. Some platforms do not have pthreads (i.e., Emscripten) and the
>>> hacks (i.e., #ifdef EMSCRIPTEN) that were added aren't great.  We may
>>> also want non-threaded builds as an option, and just using our
>>> threading functions gives us flexibility here.
>>>
>>> 2. Pthreads has been a little problematic on Windows.  In the past,
>>> when we dynamically linked to them , it caused problems when loading
>>> in DAWs where it appeared to conflict with other pthreads
>>> implementations.  We then moved to static-linking.  I think that using
>>> Windows' thread functions should be better when on Windows for
>>> performance, and it would also remove a dependency.  This in turn
>>> helps to simplify another issue:
>>>
>>> 3. I've been looking at getting  Csound buildling with Visual Studio.
>>> My plan of attack is to follow something along the lines of what I did
>>> for XCode, which is to have a script that will download all
>>> dependencies then run CMake pointing at those dependencies.  The idea
>>> is to have an easily reproducible build (and of course, to allow using
>>> VS).  Pthreads has proven to be somewhat of a pain to deal with, and I
>>> think it'd get more complicated to get to work with both x86 and x64.
>>> This part of the VS setup would be simplified if we got rid of
>>> pthreads.
>>>
>>> Comments?
>>>
>>> Thanks!
>>> steven
>>

I've started a new feature/vs2015 branch to track work on getting
Csound to compile with Visual Studio 2015.

Does anyone else have interest to help out on the thread-isolation
work?  If so, I can work on that in develop, otherwise I will just
plan to look at that in the vs2015 branch.

On Tue, Dec 6, 2016 at 12:25 PM, Steven Yi  wrote:
> Another thing to note having a non-threaded build may help in
> addressing issues with Bela (http://bela.io/) that we were looking at
> in Maynooth.  That's related to the Emscripten build as well, but it
> doesn't make sense to defined EMSCRIPTEN to build for Bela.
>
> On Tue, Dec 6, 2016 at 12:21 PM, Michael Gogins
>  wrote:
>> I am neutral with respect to this. It seems unnecessary to me, as I
>> have never had any problems using the extant open source prebuilt
>> pthreads libraries, but if you get it to work and it saves you or
>> other people problems then it's fine with me.
>>
>> We do of course have to make the Csound threading API functions
>> members of the CSOUND structure and available for plugins to call, if
>> they are not already (I think they are, but we need to be sure).
>>
>> Best,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Dec 6, 2016 at 11:47 AM, Rory Walsh  wrote:
>>> You have my blessing ;) I have been bitten by problem 2 on your list several
>>> times, but I have to admit to having limited knowledge of the consequences
>>> of changing back. I would also love to see a Visual Studio build, so if this
>>> helps, then once again you have my blessing.
>>>
>>> On 6 December 2016 at 16:41, Steven Yi  wrote:
>>>>
>>>> Hi All,
>>>>
>>>> One of the things that has been nagging me a bit is that we made a
>>>> decision a while back (I think I proposed it) to accept use of
>>>> pthreads as the base for all platforms. I think this was around the
>>>> time of Android/iOS but I am not certain.  As a result, we removed
>>>> some older code (i.e., Mac OS9) but we also have a situation now where
>>>> some files use pthread.h directly and others use csound's threading
>>>> functions.
>>>>
>>>> I'd like to go back now to using just csound's threading functions and
>>>> remove use of pthreads throughout the code base.  The reasons for this
>>>> are as follows:
>>>>
>>>> 1. Some platforms do not have pthreads (i.e., Emscripten) and the
>>>> hacks (i.e., #ifdef EMSCRIPTEN) that were added aren't great.  We may
>>>> also want non-threaded builds as an option, and just using our
>>>> threading functions gives us flexibility here.
>>>>
>>>> 2. Pthreads has been a little problematic on Windows.  In the past,
>>>> when we dynamically linked to them , it caused problems when loading
>>>> in DAWs where it appeared to conflict with other pthreads
>>>> implementations.  We then moved to static-linking.  I think that using
>>>> Windows' thread functions should be better when on Windows for
>>>> performance, and it would also remove a dependency.  This in turn
>>>> helps to simplify another issue:
>>>>
>>>> 3. I've been looking at getting  Csound buildling with Visual Studio.
>>>> My plan of attack is to follow something along the lines of what I did
>>>> for XCode, which is to have a script that will download all
>>>> dependencies then run CMake pointing at those dependencies.  The idea
>>>> is to have an easily reproducible build (and of course, to allow using
>>>> VS).  Pthreads has proven to be somewhat of a pain to deal with, and I
>>>> think it'd get more complicated to get to work with both x86 and x64.
>>>> This part of the VS setup would be simplified if we got rid of
>>>> pthreads.
>>>>
>>>> Comments?
>>>>
>>>> Thanks!
>>>> steven
>>>