We use a manual-reset event rather than an auto-reset event to cancel IO
on the pipe. This avoids unlucky cases where new IO would start just
after signalling the event and would block indefinitely while waiting on
the newly-unsignalled event.
As far as I can tell, if a read was cancelled from a background thread,
the IO operation wasn't cancelled, so the system was poking at the
stack-allocated OVERLAPPED structure after it had been removed from the
stack, at which point something else might be occupying that region of
stack memory.
I'm pretty sure Address Sanitizer should be able to catch this sort of
thing so I'm surprised it didn't complain here.
Previously, calls to `open` blocked when creating a writeable pipe.
This could cause other calls to block indefinitely, waiting for the pipe
to become available.
Now, we open the pipe in nonblocking mode, which allows us to retry
indefinitely, checking `stopReadOperation` each time to find out whether
`close` has been called and allowing a graceful exit.
Also allows optionally ignoring callbacks during disconnect, so that the
call to `connectionLost` can be bypassed when disconnect is called from
the derived class destructor.
Previously we were choosing a Visual and Colormap on initialisation of the X11 Display which could lead to bugs when opening a window with different visual and colour requirements. This commit makes 16, 24 and 32-bit visuals available and chooses the correct one when opening a window.
It was possible to encounter data races when when requesting connection
callbacks on the message thread, but creating/destroying connection
objects on a background thread.
This change ensures that a message will not be processed if the
destination connection is destroyed before the message is delivered.
Deprecated methods returning a Display& in favour of new methods returning a Display* which return nullptr when running on a system with no connected displays.
Adds a new `drawPopupMenuBackgroundForOption` member function to
`PopupMenu::LookAndFeelMethods`. By default this will pass through
to `drawPopupMenuBackground`, but it can be overridden in cases
where the background appearance depends on the current `Options`.
The recent IFileChooser update to the JUCE FileChooser meant that
Windows build machines must be running Vista or newer.
For compilers other than MinGW, we were already requiring that the build
machine must be running Windows 8 or newer.
Previously, if `AudioProcessorGraph::prepareToPlay` was called twice,
interspersed with calls to `setProcessingPrecision`, the graph would
consider the nodes 'prepared' on the second call, and wouldn't
re-prepare the inner nodes with the new precision setting.
graph.setProcessingPrecision (juce::AudioProcessor::singlePrecision);
graph.prepareToPlay (44100, 512);
graph.setProcessingPrecision (juce::AudioProcessor::doublePrecision);
graph.prepareToPlay (44100, 512); // this wouldn't update the nodes
Now, we always explicitly unprepare all nodes at the beginning of
prepareToPlay, so that they'll always receive the newest settings.
Requesting a callback when opening an Oboe device is required on some devices to get a FAST stream, so pass a dummy callback object to the temporary stream used when querying the device buffer size in order to get the best available.
If input channels have been requested but no data is being sent from CoreAudio (usually due to permissions not being granted yet) then avoid waiting unnecessarily in AudioIODeviceCombiner::readInput() which could previously cause audio glitches. Also changed the wait time to use an exponential backoff.
Some hosts (such as Reaper) weren't creating an instance of exactly
NSOpenPanel or NSSavePanel, which meant that the call to
`getSelectedPaths` was always returning an empty array.
Now, rather than trying to cast the sender to an appropriate type, we
assume that the sender is always the same panel that we opened earlier,
so that we can just query the panel directly for its selection.
Previously, the `JUCE_APP_CONFIG_HEADER` macro wasn't being defined/included
in some of the wrapper files, which meant that there was a danger of these
files building without important JucePlugin_Build_* macros defined.
Previously, when a file dialog was launched synchronously, the 'dummy' modal
component was preventing user input events from reaching the preview component.
Now, we explicitly allow input events to reach the file preview component, if
it exists.