Peter et al.,

I've finished the changes I was making to JNIAST.  It now works with
AST compiled --with-pthreads (or without) and I believe it provides
access to almost all the features available at AST 5.1.

The one AST 5ism that is not provided is the Plot3D class.
Actually writing the JNIAST code for this would take a bit of time, 
but it wouldn't be all that hard.  The general approach would be along
the same lines as the Plot class, which is to define a low-level 
java plotting interface (Grf/Grf3D) which matches the capabilities
of the AST low-level plotting interface (grf/grf3d) and fix it in
JNIAST so that AST ends up calling code which invokes methods on
that interface.  The Grf/Grf3D implementation can then be in pure Java.
One reason I haven't done all this is because
it's not clear how to provide an implementation of such a Grf3D 
interface.  I guess a Java3D implementation is an obvious answer,
but most JREs don't have Java3D, so any applications which used
this would have additional deployment issues (read: most users would
try it and find it doesn't work).  One could write the 3D from scratch
using AWT, which is what I did for TOPCAT, but it would probably be
a fair amount of work (providing both implmentations would be ideal).
Anyway, unless it becomes clear that there's somebody who actually 
wants to use AST Plot3D from Java, I don't think it's worth expending 
the reasonable amount of effort that this would require.

As detailed in earlier mails, I've changed JNIAST's use of threading
so that now no two AST calls can execute simultaneously.  I have 
added the following explanatory comment in jniast.h:

   /* 
    * Define whether multithreading will be used in invoking the AST library.
    * This is currently set false, which means there is a single per-AST
    * mutex, so that no AST call is in progress at the same time as any
    * other AST call.
    *
    * It is somewhat disappointing that this has to be the case, and it
    * means that some, but not most, of the JNIAST threading machinery
    * is doing no useful work.  It's like this.  Although AST's
    * design means that no AstObject may be accessed simultaneously
    * by multiple threads, it should in principle be possible for AST
    * calls using disjoint objects to execute simultaneously.
    * However, this can in practice lead to deadlock.  Although care is
    * taken within JNIAST to acquire locks (call astLock() on required
    * objects) in a defined order, which ought to be enough to prevent deadlock
    * (see Resource Hierarchy solution to Dining Philosophers problem),
    * there is a problem: astLock() itself does not simply acquire a single
    * lock, but potentially many, since it locks not only the requested
    * object but any object which that contains.  Since the order in which
    * it does this is not congruent with the order used by JNIAST,
    * deadlock is no longer prevented.  The only fix I can think of for
    * this would be an AST call which takes an array of objects to lock,
    * and acquires locks in some well-defined order.  If that ever comes
    * about, the following JNIAST_THREADS def should be changed to
    * AST__THREADSAFE instead.
    */
   #define JNIAST_THREADS 0

The current version builds and passes tests using a recent AST 
(git f6e1173?).  I haven't committed any of the native libraries, 
though I can do the i386 one on request.

Peter, over to you - SPLAT testing and assuming that's OK native 
library build/commits.  Please run the the tests on the various 
architectures too.  Let me know any problems.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/