Re: wxt term + osx

[Ethan A M. <sf...@us...>]

On Wednesday, 26 August, 2015 17:33:27 Allin Cottrell wrote:
> 
> I think there may be an antecedent problem here in relation to 
> wxWidgets. In wxt_gui.h we have:
> 
> #ifndef WXT_MONOTHREADED
> #if defined(__WXGTK__)
> # define WXT_MULTITHREADED
> #elif defined(__WXMSW__) || defined(__WXMAC__)
> # define WXT_MONOTHREADED
> #else
> # error "wxt does not know if this platform has to be single- or 
> multi-threaded"
> #endif
> #endif
> 
> Now, as I understand it, WXT_MONOTHREADED is defined when this code is 
> first reached if and only if the user has deployed the configure 
> option --with-wx-single-threaded (described with "do not use 
> multithreaded wxgtk even if available"). In my gnuplot build I did not 
> use that option; it's not applicable since my wxWidgets on OS X does 
> not use GTK, it's cocoa. Therefore we proceed within the cpp block, 
> and we skip 'if defined(__WXGTK__)'.
> 
> But then what happens? If __WXMAC__ is defined gnuplot then defines 
> WXT_MONOTHREADED, but why? My build of wxWidgets 3.0.2 defines 
> __WXMAC__, and __WXOSX_COCOA__, and wxUSE_THREADS, so it seems an 
> incorrect assumption is being made here.

I cannot reconstruct when/why the gnuplot code assumes that
wx on OSX must be single threaded.  
Maybe it was true for some earlier OSX versions but the restriction
was later relaxed?
Maybe it is true for wx+carbon but not for wx+cocoa?
Maybe it is not true in general, but gnuplot breaks the
threading model (event loop is in secondary not primary thread)?
Maybe it was always wrong but it was added in an attempt to
fix a problem that was ultimately due to something else?

Anyhow, if you can confirm that it works in multithread mode
also, I'd be happy to remove that assumption from wxt_gui.h.

	Ethan