On Thu, 24 Apr 2008, Malcolm J. Currie wrote:
> Exactly. They should also have separate SUNs (I note an earlier KAPPA
> offshoot, shl, doesn't yet).
*cough*
it needs to be rewritten in C now that HLP is in C.
>
>>> astronomers to use the facilities to write their own tools. Should we
>>> be converting old Fortran to C?
>>
>> No new fortran code should be written because it is completely impossible
>> to multi-thread it (I've been saying this for ages).
>
> It's often easier to adapt existing code than start from scratch.
>
> You didn't answer my question. Whether or not the new stuff is in
> Fortran isn't going to make a lot of difference to address the
> multi-threading problem, if the bulk of the applications code remains
> in Fortran. So along those lines I was wondering what can be done to
> the legacy code.
Rewriting everything is about the only thing that can be done. NDF is a
big problem (fortran). AST is another (globals). HDS uses hds_gl_status
*everywhere* (presumably because it was simple) and that has to go. EMS is
not thread-safe (the error stack is a big global and is clearly a
problem with threads).
A limited set of globals is okay (eg a pool of open HDS files) so long as
a mutex can be used to access a particular item but putting a mutex at the
top of all HDS calls is going to cause locking problems.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|