semaphore creation within a thread

SDKs Plugins
1

In a plugin a semaphore is created with

REALnewInstanceWithClass(REALGetClassRef("Semaphore"))

followed by calling the constructor method

void Semaphore_Constructor(REALobject self, RBInteger initialCount)
{
	static void (*_fp)(REALobject, RBInteger) = nil;
	if (!_fp)
		_fp = (void(*)(REALobject, RBInteger))REALLoadObjectMethod(self, "Constructor(numRes As Integer)");
	if (_fp)
		_fp(self, initialCount);
}

Unfortunately, there seems to be no way to test the validity of the semaphore?

There are two questions that relate to wanting to know the validity:

  1. is it true that in Xojo
dim mysemaphore as new semaphore(1)

can return a nil object and if so how to detect this in the plugin?
2) can a semaphore be created within a thread (thread safe)?

2

[quote=236872:@Alfred Van Hoek]REALnewInstanceWithClass(REALGetClassRef(“Semaphore”))
[/quote]

The pattern of REALnewInstanceWithClass(REALGetClassRef("...")) should be avoided. Plugins should have static variables for REALclassRefs that get assigned to during the execution of PluginMain. Doing so ensures that the dependencies are registered with the compiler and the classes aren’t dead stripped out.

[quote=236872:@Alfred Van Hoek]1) is it true that in Xojo

dim mysemaphore as new semaphore(1)

can return a nil object and if so how to detect this in the plugin?
[/quote]

It is not possible for New to return a Nil object in Xojo code. The object is either fully constructed or an exception is raised.

A Xojo thread or a pre-emptive thread? It’s definitely safe from a Xojo thread and definitely unsafe from a pre-emptive thread (along with every other SDK function).

3

I know, static references of classes are called with REALGetClassRef in PluginMain to avoid dead stripping. Having done that the pattern REALnewInstanceWithClass(REALGetClassRef(“…”)) can be used elsewhere in sub files without using the static variable. Is not that correct?

Further, my question was about creation of a semaphore in a Xojo thread. Thanks for acknowledging it is safe to create a semaphore in a thread.

4

I am wondering if it really is possible to suspend or to signal a thread to stop execution and give time to update the GUI. I’d like to do this to update the GUI “synchronously”, instead of asynchronously. The plugin calls semaphore.signal or thread.suspend after setting up a one-shot timer. This halts the thread, then the timer fires, the call to a GUI element is accomplished and it is followed by semaphore.release or thread.resume. The plugin uses method and property signatures, to invoke dynamic access in the main thread. This prevents the ThreadAccessingGUIException. I have file it as <https://xojo.com/issue/41939>, with more details, but cannot provide the community at large with the actual sample project and plugin at this stage.