On Fri, 18 Jul 2008, Tim Jenness wrote:
> 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.
Hmm, not convinced there's a need for any of this. As far as I can see
SLALIB Fortran doesn't use COMMON blocks or explicitly SAVE'd variables,
so shouldn't it be perfectly reentrant already?
Peter.
|