SuperColliderAU and AsioThread

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

SuperColliderAU and AsioThread

g.roma.lists
Hi all, I am trying to bring SuperColliderAU back to life with current SC. 
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:

Any idea?

best,

gerard
Reply | Threaded
Open this post in threaded view
|

Re: SuperColliderAU and AsioThread

brianlheim
Hello Gerard,

Thanks for reviving this!

Having you tried determining the cause and location of the crash with a debugger?

-Brian

On Fri, Dec 22, 2017 at 6:42 AM <[hidden email]> wrote:
Hi all, I am trying to bring SuperColliderAU back to life with current SC. 
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:

Any idea?

best,

gerard
Reply | Threaded
Open this post in threaded view
|

Re: SuperColliderAU and AsioThread

g.roma.lists


Having you tried determining the cause and location of the crash with a debugger?

I did not think I'd have to go that far  ;P
OK so I did now, the crash happens at 
Not that I am very familiar with the move constructor, but my guess is that since gAsioThread already holds one thread it will terminate it before getting the new one. 

best,

gerard
 

-Brian

On Fri, Dec 22, 2017 at 6:42 AM <[hidden email]> wrote:
Hi all, I am trying to bring SuperColliderAU back to life with current SC. 
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:

Any idea?

best,

gerard

Reply | Threaded
Open this post in threaded view
|

Re: SuperColliderAU and AsioThread

brianlheim
OK, that helps. This has nothing to do with Boost.Asio, it turns out. SC_Thread is a typedef for std::thread. Trying to do a move assign there will not join the thread; in fact, trying to destruct an unjoined or undetached thread will cause early termination [of the entire program] (http://en.cppreference.com/w/cpp/thread/thread/%7Ethread). I think it's fair to say there is meant to be only one of those running.

Also, to be more accurate, that line is performing move assignment, not construction.

This appears to be a recent addition (4 years ago). Is it absolutely necessary for you to call World_New multiple times? Perhaps we could alter this code to avoid constructing a new asio thread if one is currently running (i.e., `if (gAsioThread && gAsioThread.joinable())`). Maybe try that out and see if you run into any other issues.

-Brian

On Fri, Dec 22, 2017 at 9:59 AM, <[hidden email]> wrote:


Having you tried determining the cause and location of the crash with a debugger?

I did not think I'd have to go that far  ;P
OK so I did now, the crash happens at 
Not that I am very familiar with the move constructor, but my guess is that since gAsioThread already holds one thread it will terminate it before getting the new one. 

best,

gerard
 

-Brian

On Fri, Dec 22, 2017 at 6:42 AM <[hidden email]> wrote:
Hi all, I am trying to bring SuperColliderAU back to life with current SC. 
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:

Any idea?

best,

gerard


Reply | Threaded
Open this post in threaded view
|

Re: SuperColliderAU and AsioThread

g.roma.lists
 Is it absolutely necessary for you to call World_New multiple times?
I think it would not work otherwise, I could try duplicating it but it would look ugly.
 
Perhaps we could alter this code to avoid constructing a new asio thread if one is currently running (i.e., `if (gAsioThread && gAsioThread.joinable())`). Maybe try that out and see if you run into any other issues.

yes I was looking for some form of that that the compiler will like ;)

best,

gerard



 

-Brian


On Fri, Dec 22, 2017 at 9:59 AM, <[hidden email]> wrote:


Having you tried determining the cause and location of the crash with a debugger?

I did not think I'd have to go that far  ;P
OK so I did now, the crash happens at 
Not that I am very familiar with the move constructor, but my guess is that since gAsioThread already holds one thread it will terminate it before getting the new one. 

best,

gerard
 

-Brian

On Fri, Dec 22, 2017 at 6:42 AM <[hidden email]> wrote:
Hi all, I am trying to bring SuperColliderAU back to life with current SC. 
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:

Any idea?

best,

gerard



Reply | Threaded
Open this post in threaded view
|

Re: SuperColliderAU and AsioThread

brianlheim
> I think it would not work otherwise, I could try duplicating it but it would look ugly.

All right! Not very familiar with what you're doing so I just wanted to make sure.

On Fri, Dec 22, 2017 at 10:28 AM, <[hidden email]> wrote:
 Is it absolutely necessary for you to call World_New multiple times?
I think it would not work otherwise, I could try duplicating it but it would look ugly.
 
Perhaps we could alter this code to avoid constructing a new asio thread if one is currently running (i.e., `if (gAsioThread && gAsioThread.joinable())`). Maybe try that out and see if you run into any other issues.

yes I was looking for some form of that that the compiler will like ;)

best,

gerard



 

-Brian


On Fri, Dec 22, 2017 at 9:59 AM, <[hidden email]> wrote:


Having you tried determining the cause and location of the crash with a debugger?

I did not think I'd have to go that far  ;P
OK so I did now, the crash happens at 
Not that I am very familiar with the move constructor, but my guess is that since gAsioThread already holds one thread it will terminate it before getting the new one. 

best,

gerard
 

-Brian

On Fri, Dec 22, 2017 at 6:42 AM <[hidden email]> wrote:
Hi all, I am trying to bring SuperColliderAU back to life with current SC. 
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:

Any idea?

best,

gerard




Reply | Threaded
Open this post in threaded view
|

Re: SuperColliderAU and AsioThread

g.roma.lists
So this seems to fix it for starting new instances:

if (!gAsioThread.joinable()){
SC_Thread asioThread (&asioFunction);
gAsioThread = std::move(asioThread);
}

However the host will still crash when exiting after allocating more than one instance, so I'll keep beating it...

thanks

gerard


2017-12-22 17:30 GMT+01:00 <[hidden email]>:
> I think it would not work otherwise, I could try duplicating it but it would look ugly.

All right! Not very familiar with what you're doing so I just wanted to make sure.

On Fri, Dec 22, 2017 at 10:28 AM, <[hidden email]> wrote:
 Is it absolutely necessary for you to call World_New multiple times?
I think it would not work otherwise, I could try duplicating it but it would look ugly.
 
Perhaps we could alter this code to avoid constructing a new asio thread if one is currently running (i.e., `if (gAsioThread && gAsioThread.joinable())`). Maybe try that out and see if you run into any other issues.

yes I was looking for some form of that that the compiler will like ;)

best,

gerard



 

-Brian


On Fri, Dec 22, 2017 at 9:59 AM, <[hidden email]> wrote:


Having you tried determining the cause and location of the crash with a debugger?

I did not think I'd have to go that far  ;P
OK so I did now, the crash happens at 
Not that I am very familiar with the move constructor, but my guess is that since gAsioThread already holds one thread it will terminate it before getting the new one. 

best,

gerard
 

-Brian

On Fri, Dec 22, 2017 at 6:42 AM <[hidden email]> wrote:
Hi all, I am trying to bring SuperColliderAU back to life with current SC. 
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:

Any idea?

best,

gerard