General Questions about Plugin Dev and Threading

Serethos wrote:
If breve calls a method from a plugin, which only starts a thread (so that the original plugin methods comes to end) does breve quit the whole plugin process so that the started thread will die or does this second thread live further?

The second thread should definitely live on for as long as the simulation is running.

When the simulation ends, funny stuff might happen since breve will try to unload the module, so it would be best to make sure that your thread exists before the simulation ends.

Quote:
2:
My plan was to have (for testing purposes) a second programm which communicates with breve run at the same time. But breve really blocks the whole system while running the simulation. So it is nearly impossible to have anything other than breve executing. Is there any way to avoid this?

You're running on Windows, correct? I have heard reports that the Windows version changes its own process priority (!?), but I don't know why/how this is happening since I didn't put it into the code. If you change the process priority back down again, you should be able to run something else at the same time.

- jon

Thx for the fast reply jon. The server thread is now running but the problem of thread priority is still there. You are right that you can handle the priority via Win XP, but even setting Breve to lowest (non idle) priority gives it far too much resources. To give an example: Running breve with an echo-server plugin and echoing one(!) byte via a second standalone program (which takes much time to start) requires up to 10 sec.

But besides this problem I have another one. Is there any possibility to call a breve method from within a plugin?
I have a little "who calls whom" problem: My standalone program sends a command to the server plugin of Breve. Breve shall execute it and send an evaluation back, so it takes the role of a server listening for requests.
So if the server (which lies in its own thread) gets a command at a given time how can it report to breve that it should start to evaluate?
The only way I can see is some kind of consumer/producer polling:
Breve starts the server and continuously asks a Polling Queue of the server plugin if something has arrived. But I would find it much more elegant to have a messaging mechanism instead of polling.

I will add an option to make the engine sleep between each frame to force breve to use less resources.

For the second problem, yes, you can call a breve method from a plugin, but the fact that you asked that question made me realize there might be a problem with it.

In the header file include/breve/breveObjectAPI.h, you'll find the following functions which will let you call objects in breve:

DLLEXPORT int brMethodCall(brInstance *, brMethod *, brEval **, brEval *);
DLLEXPORT int brMethodCallByName(brInstance *, char *, brEval *);
DLLEXPORT int brMethodCallByNameWithArgs(brInstance *, char *, brEval **, int, brEval *);

HOWEVER, these methods are not currently thread-safe (because breve isn't currently multithreaded), so unfortunately, I would have to advise against using them until I can provide a way to externally lock the engine. That will just involve exporting some additional symbols though, so I should be able to do it relatively quickly.

- jon

Ahh it's terrible, every solution has a drawback :)

I will try the approach with the polling method though I am not sure how breve will behave polling.
But I am a little confused that breve does not use multiple threads. I am not really a c programmer, my roots are in java, but AFAIK if you want to support a gui which does not lock during calculations you have to separate gui and algorithm with at least two threads. So if a normal simulation runs, the gui does not block! but if I use my server, the complete gui hangs. Thats the only reason why I need another thread. My program is in the heart fully serial: Wait for instructions, execute, report back. Nothing real parallel.
If only the gui would'nt block ..

I've uploaded an updated version of breve which includes a simulation speed menu which will allow you to throttle back the breve simulation to allow more time to other processes.

Also, this version exports the symbols brEngineLock and brEngineUnlock, which will allow you to safely lock the engine before calling breve methods from your plugin. You'll need the header file from the latest source code in the subversion -- it's include/breve/breveObjectAPI.h .

http://spiderland.org/breve_2.5d/

As for the threading question, yes, breve does use multiple threads for the interface and the engine. I just meant that the engine itself (which does the simulation computation) is not multi-threaded.

- jon

Ah John you're a sweetheart! Thx for modding breve I will immediately try the changes!

BTW: If the engine and the gui run in its own thread, why does my socket-server block the gui then?

Hmm, perhaps the mistake lies by myself, but including the breveObjectAPI.h
produces a BUNCH of errors, mainly in methods and variables the c interpreter can not find (I think). Perhaps you get the idea looking at the output:

-- removed --

I really do not like to bombard people with such a list of errors but I really can't handle them.

I have experimented a little to get this problem done by myself. The errors result in missig declarations of some breve intern types like 'slStack' etc.
I do not understand how this header could work for your build (because the header does not include any headers or defines the structures). So I tried to include the headers which define the structures and this cleared a lot of problems.

I included:

#include "utilTypedefs.h"
#include "kernelTypedefs.h"

Now there is only one thing left, a declaration conflict of

breveObjectAPI.h declaration of C function `int brMethodCallByNameWithArgs(brInstance*, char*, brEval**, int, brEval*)' conflicts with 

slBrevePluginAPI.h previous declaration `int brMethodCallByNameWithArgs(void*, char*, brEval**, int, brEval*)' here 

I see that these definitions are equally useable but I am not sure if I hack more problems into the issue than solving when I only disable one. It would be nice to hear if theres some mistake.

I had been going through the header myself -- these declarations are indeed equivalent and you can comment out the plugin version.

- jon

First of all I am very happy that the development with breve got a real boost now that the plugin is running and I am able to have bidirectional communication. But there is still one issue: the call to brLockEngine(..) crashes breve (the whole gui is blocked, you can see only a white screen).

At the moment it seems no problem to call the "thread-unsafe" way:
start server plugin -> wait for commandos -> call breve -> execute commando

is a very serial process and perhaps I can guarantee that breve is doing nothing while the possibility of a breve method call exists. But the question is if that is enough. I do not know what breve does behind the scences.

Just to be sure that this is not a mistake by myself, i used the calls that way:

brEval result;
brEngineLock(breve->engine);
brMethodCallByName(breve , "pluginCall", &result);
brEngineUnlock(breve->engine);

Your calls do look right. And you're calling this from a separate thread, not in the same engine thread in response to a plugin call, correct?

It *sounds* like the engine is already locked in the same thread and that you're getting a threadlock. But if this is really happening in another thread, I don't see how that would be happening.

- jon