Thread-safety will be useful, thanks.
The matrix should be protected internally, I think. There are only a
few calls that models make on the matrix, and some by the raytracer.
The main issue there would be trying to keep the number of lock/
unlock ops to some reasonable level for performance.
Please don't spend any time figuring out RTK. I have an almost-
complete OpenGL branch in cvs now, that will become HEAD and then
Stage-2.1.0 before very long. Of course, OpenGL is absolutely not
thread-safe, so I'll try to keep in mind that we'll need to protect
if you want to peek at the GL version, get the new dependency
$ cvs co -r opengl stage
It looks fairly normal until you hold down CTRL and drag the window.
No need for complaints about how it doesn't work, or works funny. I
know already, and I'm working on it when I can.
On 15-Sep-06, at 1:26 PM, Reed Hedges wrote:
> As I described a few weeks ago, MobileSim accesses libstage from
> threads. Using GLib and GTK with multiple threads is not really the
> best idea in
> the world, but it was fairly easy to get most of it working right;
> there's one
> very tricky aspect that I'll mention later, and would be
> appreciative of any help.
> Here's what I changed in my fork of libstage 2.0.0a (if i'm wasting
> my time and
> I should move to 2.0.1 now rather than later, please let me know!):
> * Each model has a mutex, and there are functions stg_model_lock
> and stg_model_unlock(stg_model_t*). This code was already present,
> commented out.
> * Added a mutex to the world
> * Added a flag to the world, which determines whether
> stg_world_update() locks
> each model during its update or not; no other code within libstage
> does any
> locking or unlocking, the rest is left up to the application. By
> stg_world_update() does not do any locking.
> The goal was to make libstage "optionally sort of threadsafe". That
> is, it
> provides tools that applications can use to make it threadsafe.
> I added one more mutex, but it's not as nice as the above, so I
> consider it a
> hack that should be fixed: the world matrix is "shared" among the
> models and
> various model callbacks etc. modify it. So I put a mutex around
> that, but I had
> to lock it in all kinds of random ad-hoc places inside libstage,
> since there's
> no easy way to tell which functions in the public API will be
> modifying the
> matrix, unless you happen to know what exactly all those functions
> do. So we
> could either document that (error-prone), or do a proper job of
> locking the matrix (messy though; maybe just re-use the world
> mutex, and also
> have a flag to enable/disable locking it? though that would result
> in some
> uneccesary contention for the world mutex though... any ideas?)
> This all seemed to work pretty well, but as I started testing with
> more and more
> robots (by the way, after a few timing changes I'll describe in
> another email,
> stage has been performing decently with about 100 robots I think
> the main limit
> was stage plus my 'wander' programs for each robot maxing out my
> abilities about here) I started getting a few random crashes in glib.
> Since I'm not that familiar yet with the RTK levels of libstage,
> I'm not sure
> excatly what it is but it seems that either I'm neglecting other
> kinds of data
> shared between models and the world (as the world matrix is), or
> some data is
> used directly by GTK when it does the drawing. I've mostly solved
> this in an
> ad-hoc manner, like the matrix problem, but it's not pretty. So
> again, more
> information on what data is conceptually "shared" between libstage
> objects, or
> GTK, or even just about how RTK drass figures in GTK would help.
> In general, stage has proved to be very hackable and easy to
> understand and
> modify, so great job and thanks Richard, Andrew and others for
> creating it!
> Thanks for any ideas or comments,
> Using Tomcat but need to do more? Need to support web services,
> Get stuff done quickly with pre-integrated technology to make your
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Playerstage-developers mailing list