2008/7/18 Tim Jenness <[log in to unmask]>:
> 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.
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...
> - 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.
Fair enough.
> - the reentrant versions should always be built, so again,
> --with-pthreads should not be needed.
OK.
David
|