Previously, the Lock was not thread-safe when multiple threads were
locking/unlocking a single Lock instance simultaneously. This
isn't normally a problem when using the MessageManagerLock type, because
each MessageManagerLock contains its own private MessageManager::Lock,
and it's not possible for multiple threads to modify that private lock.
This change improves safety when using a MessageManager::Lock in the
manner of a CriticalSection or other JUCE lock type.
Previously, the following sequence of events was possible:
Background thread Main thread
------------------------------------------------------------------------
Lock::tryAcquire()
Run to blockingMessage->post()
BlockingMessage::messageCallback()
Run to abortWait.set (1)
Lock::tryAcquire()
Exit through return true
Lock::~Lock()
Destroy memory used for Lock
BlockingMessage::messageCallback()
Execute lockedEvent.signal()
Memory already freed, crash
In order to display a WebKit based webview a plugin will deploy a
temporary standalone executable on the system and host the WebKit
instance inside that.
This commit reverts c34f13a02d
In stripped plugin builds, the repostCurrentNSEvent function was still
public. There doesn't seem to be a good reason for this, as no host
should need to call the function.
It looks like the shared code component of a Projucer-generated plugin
project was briefly built as a framework that was shared by the
different plugin wrappers. In this scenario, the framework would need to
make repostCurrentNSEvent public so that the wrappers could locate the
function. However, now that the shared code target is built as a static
library, standard external linkage should be sufficient for the symbol
to be located from the wrapper's TUs.
