Hi Dan,

I'm building as I type this message.  My first thought is about wxEvents.  I think you've delved into the wx event system further than I have, but I do remember something about wxCommandEvent being slightly not threadsafe, and causing certain operations to fail.  This comes from the fact that wxCommandEvent contains a wxString, which is NOT thread safe.
 This apparently does not cause an issue for some event usage, but if you get strange crashes, this is something to consider: 
As recently as 2008 Vadim Zetlin explains this:
http://www.archivum.info/comp.soft-sys.wxwindows/2008-04/msg00456.html

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 <danhgn@googlemail.com> wrote:
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
> minutes.
>
> 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.

Best,

Michael