Re: threading troubles on OSF Alpha v3.2 (ITS#89)

[h.b.furuseth@usit.uio.no]

Kurt D. Zeilenga writes:
> This is draft 4 behavior.  I assume HAVE_PTHREADS_D4 is defined
> and HAVE_PTHREADS_FINAL is not?
> 
>> Can we put it back, this time in libldap_r/thr_posix.c?
> 
> Yes.
> 
> s/PTHREAD_STRUCT_ARGUMENTS/HAVE_PTHREAD_D4/

OK, will do.   (Well, HAVE_PTHREAD!S!_D4 actually.)


But more is coming up though:

* pthread_yield() returns void, not int.  Is that D4 too?
  If so I could add this in ldap_pvt_thread_yield:

	 #ifdef HAVE_SCHED_YIELD
	        return sched_yield();
	+#elif HAVE_PTHREAD_YIELD && HAVE_PTHREADS_D4
	+       pthread_yield();
	+       return 0;
	 #elif HAVE_PTHREAD_YIELD
	        return pthread_yield();
	 #elif HAVE_THR_YIELD
	        return thr_yield();

  Or I could change ldap_pvt_thread_yield to return void; its return
  value isn't used anywhere in the ldap source anyway.


* _r functions:

  (Should I reopen the old ITS reports and repost this report there?)

  ctime_r on OSF1 v3.2 returns an int status (-1 or 0) instead of the
  buffer.  We have no configure test which detects that, or detects that
  ctime_r doesn't work as expected.
  

  gethostby{name,addr}_r take a 'struct hostent_data *' argument
  instead of the bunch of extra arguments used elsewhere.
  It must be zero-filled before its _first_ access by gethostby*_r.
  (I'm not sure what that means: per thread or per process or what.)

  I still think it's better to turn off HAVE_GETHOSTBYNAME_R & co
  instead of aborting compilation if we bump into an implementation we
  don't know how to handle.  (That doesn't mean I object to another
  configure test of course, but if this is a "private solution" I
  suspect we'll keep bumping into more private soutions.)

-- 
Hallvard