On Tue, 24 Feb 2009, Mark Taylor wrote:
> 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?
Don't see any updates to JNIAST, did you mean to merge them from the
development branch?
Peter.
|