So I would also recommend not using any wxStrings in your shared script-main thread data.
About where to block:
On Sun, May 31, 2009 at 1:55 PM, Dan Horgan <email@example.com>
On Sun, May 31, 2009 at 03:52:36PM +0100, James Crook wrote:
> Dan Horgan wrote:
> > Rather than sending the
> > data back to the script thread (awkward since the events system can't be
> > used) I think it makes sense to let the main thread do the output, by
> > calling a function in the plugin. Since this would be done before the
> > event handler returns, commands would still be executed one at a time
> > and in the right order even if the script ignores the responses.
> I don't think that is a good solution. Audacity GUI could hang waiting
> on the script in that case. For example if the script has been killed
> during processing the command. I'm not sure that is the case for pipes,
> but for TCP/IP it could be doing retries and so on that could go on for
> I think that doing the 'awkward thing' is necessary. You do need to get
> data back from the gui thread to the non gui thread. You'd use a mutex
> to protect an object or pointer used to share data between the two
> threads, and that would be picked up on the next poll from the non-gui
> thread, or pause and resume the non gui thread if the non gui thread
> needs to wait.
> I'd think the non GUI thread usually does need to wait - for the
> majority of operations that it invokes (play and record are possible
> exceptions that may need something more advanced).
> It is quite possible I've got things wrong here. If that's the case
> please argue it until it is clearer.
There are other advantages to letting the main thread execute the entire command - If you use the main thread for the user input only, and then do the command execution on the script thread, you will be a TON more resources that are currently non-threadsafe in audacity. It seems to me like you might want to pass some info back to the scripting thread - but maybe this should just be data about the scripting itself (e.g. %completed, user hits cancel).
Is there an example that makes this difficult? I may be misunderstanding something - if so, please clarify.
Looks good overall, I'm excited about playing around with it. I hope to give test results back on tuesday. I have finals mon and tues morning, but will keep an eye on this thread.