On Fri, 18 Jul 2008, Peter W. Draper wrote:
> We'll see...
I've got a couple of comments on threads here.
1. --with-pthreads has to be the default at some point before release
since, for example, SMURF won't be working without pthreads so how do we
get make world to complete otherwise? We should only build without threads
if threads aren't supported on the platform. AST builds two versions for
speed and that is fine, EMS only needs one version since speed is not
normally an issue when reporting errors.
2. Those new thread-safe sla patches. I'm a bit concerned since:
- linking against the C SLA is now not possible (I would imagine that
C SLA is already thread-safe but I haven't checked for statics).
Since there are no API changes for the _r I imagine we would be able
to get away with an include file that uses a macro to turn them into
normal C SLA versions.
- installed include files can't use CONFIG_H to check for behaviour
because they don't know which tests were used to generate the current
config.h. sla_r.h should always define the prototypes.
- the reentrant versions should always be built, so again,
--with-pthreads should not be needed.
>
>> I had a quick look at porting MERS to C (at least the bits that don't call
>> subpar) and I'm a bit stymied by the msg_fmtX routines since they take
>> fortran format descriptors and I have no idea to handle that in C (although
>> one idea would be to change the API to use C sprintf formats and modify the
>> Fortran code to use C rather than fortran format strings - the advantage of
>> having nearly all the code in one place).
>
> Well you could do that, but since you'll not be able to evade Fortran all
> together, why not leave these alone and stick them in a Fortran library, and
> add a Conly flag to the linker scripts. I doubt not having these functions is
> a major pain for the C users.
>
Yes. Should be easy to have a msgFmti that uses C printf style if needed.
--
Tim Jenness
JAC software
http://www.jach.hawaii.edu/~timj
|