[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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

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:

	        return sched_yield();
	+       pthread_yield();
	+       return 0;
	        return pthread_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.)