On 14-Oct-05, at 11:06 AM, Brian Gerkey wrote:

On Oct 14, 2005, at 5:17 AM, Reed Hedges wrote:

Richard vaughan wrote:

Property callbacks are called immediately. They are not thread safe. I experimented with a mutex on each model but it was very slow. In theory a mutex on each property would minimize blocking, but I  suspect that the system call overhead would still be tough as we access properties a LOT. A thread-safe compile-time option would be a good compromise. It's easy to do as only the stg_model_get/set_property() functions need to be modified. But this relies on the rest of the code ONLY using these functions to get at properties - that would need to be carefully checked to avoid awful bugs. GTK doesn't actually do any drawing until its update function is called, once per Stage main loop.

In the past, I've tried making calls to GTK threadsafe with a mutex, but even then had problems (because GTK and the window system are doing all kinds of things in background threads without locking, I presume, or GTK just needs to always be called from the main thread).

Well, a hack around the property callback is to have an update function check a flag set on the property...

There's a pretty good explanation of GTK/GDK/Glib's threading functionality here:


Basically, you need to wrap all GUI calls with the appropriate enter/leave functions.  I looked at doing this to Stage, in order to allow drivers to pop up debug GUIs in the same Player process as Stage, but it seemed like a lot of work.

I looked into this too, and decided against it. I'm working on a solution whereby any player driver or client can request graphics services via a graphics interface (built over the new, top-secret-but-in-the-tree database interface). Stage will either implement the graphics interface, or I'll write a pure graphics driver that Stage will use. Haven't decided which it'll be yet. Comments, queries and abuse are welcome on this idea. 



This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Playerstage-developers mailing list


Richard Vaughan

School of Computing Science / Simon Fraser University