UnixWare 7.1.4 (and OpenServer) sigwait issue

I don't think anyone replied to your questions below so let me try.

I am afraid this falls in the same category as the HP-UX patch, in that
it is for threading on an older platform and is more for a single site
rather than something where more users can benefit.

It would be interesting if you could host a web page, perhaps on our
wiki, that lists patches for older platforms so we don't lose this
information and it might be helpful to use some day.

---------------------------------------------------------------------------

Andrew Chernow wrote:

Continuing http://archives.postgresql.org/pgsql-hackers/2009-01/msg01762.php

Bruce Momjian wrote:

Well, this helps explain why were are getting these problems reports
only now. How many hacks do you have that we don't support, aside from
the threading one for HPUX?

Compiling threaded libpq on UnixWare fails on sigwait.

I quickly setup a test for unixware 7.1.4. The only issue I found was with
sigwait. Although unixware does have a 2arg POSIX.1c version, it requires
setting _XOPEN_SOURCE and _POSIX_C_SOURCE in such a manner that breaks other things:

(http://uw714doc.sco.com/en/man/html.3pthread/sigwait.3pthread.html).

My solution was:

1. added the below to configure.in line 1620, same section as
PGAC_FUNC_POSIX_SIGNALS checks.

AC_MSG_CHECKING(for POSIX.1c sigwait)
AC_TRY_COMPILE([#include <signal.h>],
[sigwait((const sigset_t *)NULL, (int *)NULL)],
[AC_DEFINE(HAVE_POSIX1C_SIGWAIT, 1,
[Define if the system includes a POSIX.1c sigwait])
AC_MSG_RESULT(yes)],
[AC_MSG_RESULT(no)])

2. Remove the sigwait prototype declaration from src/test/thread/thread_test.c.
I do not know why it is forcing the 2 arg version of sigwait? Any insight
would be helpful. Maybe it is for good reason.

3. Update fe-secure.c line 1337, the only place that uses sigwait, to the below:

#ifdef HAVE_POSIX1C_SIGWAIT
sigwait(&sigpipe_sigset, &signo);
#else
signo = sigwait(&sigpipe_sigset);
#endif

If these changes seemare acceptable, I will provide a formal patch. BTW,
openserver has the same issue so this kills two birds with one stone. Not sure
if openserver has other issues yet, test scheduled for Monday.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

I am afraid this falls in the same category as the HP-UX patch, in that
it is for threading on an older platform

Really? It was released in 2004 (maintenance pack 4 released in June 2008).

It would be interesting if you could host a web page, perhaps on our
wiki, that lists patches for older platforms so we don't lose this
information and it might be helpful to use some day.

That sounds like an interesting idea. I was already considering putting it on
the libpqtypes.esilo.com website. Maybe a better place would be on the pgwiki.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Andrew Chernow wrote:

I am afraid this falls in the same category as the HP-UX patch, in that
it is for threading on an older platform

Really? It was released in 2004 (maintenance pack 4 released in June 2008).

Oh, I didn't know that. We have had lots of problems with SCO/Unixware
bugs in the past so there is no great love for keeping that platform
going. Also, there is much threading API churn that we haven't been fond
of trying to get everything working.

It would also be nice if someone else said they wanted this to work. ;-)

It would be interesting if you could host a web page, perhaps on our
wiki, that lists patches for older platforms so we don't lose this
information and it might be helpful to use some day.

That sounds like an interesting idea. I was already considering putting it on
the libpqtypes.esilo.com website. Maybe a better place would be on the pgwiki.

Yea, probably. It would help us gather interest and perhaps include
them someday.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

going. Also, there is much threading API churn that we haven't been fond
of trying to get everything working.

The provided pthreads is 100% busted on unixware. I'd only recommend its use to
someone I don't like :) This is one of several platforms that we use the GNU
Pth library as a replacement. Providing a patch is only half the issue, one
must use GNU Pth.

It would also be nice if someone else said they wanted this to work. ;-)

Yeah. Not sure how popular unixware is. We don't see it much, but we do see
lots of openserver.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Andrew Chernow wrote:

going. Also, there is much threading API churn that we haven't been fond
of trying to get everything working.

The provided pthreads is 100% busted on unixware. I'd only recommend its use to
someone I don't like :) This is one of several platforms that we use the GNU
Pth library as a replacement. Providing a patch is only half the issue, one
must use GNU Pth.

OK, so you are confirming my suspicions and leanings. This reinforces
the idea of adding a wiki entry where these details can be documented.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +