On Thu, 19 Feb 2009, Peter W. Draper wrote:
> On Thu, 19 Feb 2009, Mark Taylor wrote:
>
> > > When this happens there is a thread running that is loading the spectra,
> > > which are then "displayed", that then triggers the event thread and the
> > > spectra are really drawn, but need to have their coordinate systems
> > > matched, so bang, access of the same AST objects from two threads.
> > >
> > > Is there a way I can switched this additional cleverness off, so I can
> > > check
> > > that fixes this?
> >
> > If you fix the definition of JNIAST_THREADS to 0 in src/jni/jniast.h
> > (by default it depends on whether AST was built --with-pthreads)
> > and do a build-native then there will be a per-AST lock so this might
> > go away - but I still want to know why it's happening.
>
> Thanks, tried that and the problem does seem to have gone away.
>
> > > It may also be possible to solve this by changing the ordering of events,
> > > but that remains to be seen.
> >
> > I hope we can address this at the JNIAST level rather than have to have
> > applications tiptoeing around the threading issues.
>
> OK, I'll leave this alone until you kick me again.
<kick/>. I've incorporated David's astUnlock() change so the error
ought not to cause trouble any more. Can you update/rebuild AST,
reset JNIAST_THREADS to its default (== AST__THREADSAFE),
build-native JNIAST and see if SPLAT is happier now?
thanks for git help BTW.
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|