On Jul 18, 2008, at 8:30 AM, David Berry wrote:
> 2008/7/18 Tim Jenness <[log in to unmask]>:
>> On Fri, 18 Jul 2008, Peter W. Draper wrote:
>>
>>
>> - 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.
>
> Not sure I follow. The old wrappers are still available in sla.o, with
> the new ones in sla_r.o. Both of these object modules are included in
> libsla, so are available for the linker when you use sla_link(_adam).
> Code that wants to use a threadsafe sla routine specifies the "_r"
> variant in the source code. Code that wants to avoid the overhead of
> the threadsafe variant can still specified the original routine name.
>
> I'm probably missing something here...
>
The problem is that if you link against Pat's C version of sla instead
of the fortran version with the C wrapper it is automatically
reentrant. Prior to today a user always had the option of inserting
the C version into the tree and building against that. Now they don't
have that option.
This may be a minor thing but we're extending the SLA C API in a way
that is not necessary for the C slalib.
#define slaObs_r slaObs
in Pat's C slalib.h would fix it but that's not really something that
we should need to ask.
I realise that we have no choice without slowing down every sla C call
with a mutex.
Wibble
--
Tim Jenness
Joint Astronomy Centre
|