Re: Same old AIX problem

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 11:08 AM 8/24/99 +0200, Frédéric Poels wrote:
>At 11:22 23/08/99 -0700, you wrote:
>>At 11:53 AM 8/23/99 +0200, Frédéric Poels wrote:
>>>Here's what happens:
>>>...
>>>-> HAVE_PTHREADS_D4 is not defined
>>>status = pthread_create(&t, NULL, task, NULL);
>>>-> OK status is 0 but as a default, threads are created DETACHED on AIX
>(!!!)
>>>...
>>>-> HAVE_PTHREADS_D4 is not defined
>>>status = pthread_create(&t, NULL, task, NULL);
>>
>>s/create/detach/, I assume.
>
>It's not that simple...
>
>>>-> KAWABUNGA! status is 3!
>>
>>>Here's the code that should be used instead (I think it's more portable
>>>even on <beeeeeep> OS'es like AIX):
>>
>>It's not portable.   Draft4 pthreads doesn't even define
>>a detached-state attribute nor have any mechanism to create
>>a thread in a detached state.  pthread_detach() must be used
>>on these systems.
>
>So what about AIX?  Will it be an unsupported OS?

No, it will be supported.  It just that autodetect on
certian revisions of AIX may fail and some user intervention
may be required.  No matter how much detection code you
put into a configure script, there will always be some
environment configure won't handle (especially in the age
of on-demand vendor patches and widely available, highly
portable 3rd party subsystems).

Folks must realize that primary goal of configure is to
detect incompatibilities.  Resolving incompatibilities is
secondary.  There are some incompatibilities that are
not adequately resolvable without user invention.

I am happy to work with you in resolving the detected
incompatility.  However, it is not an easy task.  It may
take significant reworking of the pthread detection code
to handle this particular case.

>>One should also note that mucking with thread attributes is
>>quite problematic.  We'd have to detect if pthread_attr_setdetachstate
>>exists and, if so, how to call it.  We'd also have to detect if
>>pthread_attr_delete or pthread_attr_destroy should be called.
>>To make matters worse, the syntax of may calls which accept
>>thread attributes differ from draft to draft (ie: implementation
>>to implementation).
>
>What about #ifdef _AIX or #ifdef _AIX32?

Such defines usually apply to a large set of operating systems
revisions and as such are not well suited for testing functionality
that differs between revisions.   Their use also tends to interfer
with the use of third party libraries.

So, as I noted above, for configure to handle this, configure
will need to implement a number of header tests to determine
which function prototypes are available.  In particular, it
would need to determine which pthread_attr routines are listed
and how to call them.  Then, assuming it finds a usable set,
the run test can be modified to make use these calls.

Kurt