#44 Make API re-entrant for multithreading

Discussion on the list about making the API re-entrant - logging
here as a feature
request.

-dair

*****

James Dessart wrote:

Is there a list somewhere of what Quesa functions are, or are not,
reentrant? It'd be nice to be able to push some of the more
compute-bound functions out into multi-processor threads on the
Mac OS, in our application.

*****

Dair Grant wrote:

At present nothing is officially re-entrant - there aren't any locks
whatsoever. In practice you would probably find that the math
routines are probably safe, although even they should really have
some protection in their glue around the global error state (or
make the error state thread specific).

Doing a first pass on thread safety (i.e., one global lock which was
acquired/released by every entry point) would be fairly easy since
it could be munged into the glue code.

Allowing multiple threads inside Quesa at once would be more
complex, although you could probably get most of the way there
by having per-object locks since most routines pass the object
they're working on around.

There is only bit of global data, so protecting that+the objects the
current thread is working on would probably be enough (assuming
a thread safe C library/OpenGL).

I suppose it depends on what the performance gains of doing that
wold be vs the complexity of the extra locks.

My guess is it'd only really be worth it for things like the math
routines, where you might want to dump transforming an array of
vertices off to another thread?

*****

James Dessart wrote:

It's pretty much just the math routines, and perhaps setting
TriMesh data. Essentially, playing around with coordinates and
such, without any rendering.