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
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 replace
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/Unixwa
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 old
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 co
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
Clarification, this is the email used to make the patch that was
backpatched.
---
Albe Laurenz wrote:
> >>> I have tried --with-thread-safety and configure fails on ldap check
> >>> because for some reason CTHREAD_FLAGS (-Kp
>>> I have tried --with-thread-safety and configure fails on ldap check
>>> because for some reason CTHREAD_FLAGS (-Kpthread for UW) is missing
>>> on compile command, although present before that. I can't find why
>>
>> You mean PTHREAD_FLAGS, right?
>>
> Nope,I mean PTHREAD_CFLAGS witch is define
Hi Albe,
On Mon, 18 Dec 2006, Albe Laurenz wrote:
> Date: Mon, 18 Dec 2006 09:31:35 +0100
> From: Albe Laurenz <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr, Tom Lane <[EMAIL PROTECTED]>
> Cc: pgsql-hackers list
> Subject: RE: [HACKERS] unixware and --with-ldap
>
>
>>> If libldap_r.so does require the same libs, please add
$EXTRA_LDAP_LIBS
>>> to the 'LDAP_LIBS_FE="-lldap_r"' line as well.
>>
>> Actually, I did that in the patch-as-committed. It seems to me that
>> it's probably harmless even if not needed.
>
> I have tried --with-thread-safety and configure
On Fri, 15 Dec 2006, Tom Lane wrote:
> Date: Fri, 15 Dec 2006 10:20:44 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Albe Laurenz <[EMAIL PROTECTED]>
> Cc: ohp@pyrenet.fr, pgsql-hackers list
> Subject: Re: [HACKERS] unixware and --with-ldap
>
> "Al
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> You left out the case where --enable_thread_safety is specified.
> ...
> If libldap_r.so does require the same libs, please add $EXTRA_LDAP_LIBS
> to the 'LDAP_LIBS_FE="-lldap_r"' line as well.
Actually, I did that in the patch-as-committed. It seems t
Martijn van Oosterhout wrote:
>> I guess that adding $EXTRA_LDAP_LIBS to -lldap_r will be enough,
>> judging from the evidence on Linux.
>
> Linux doesn't need the extra libraries, it's linked properly.
Yes - what I mean is, libldap_r.so references only
NEEDED libsasl.so.7
NEEDED li
On Fri, Dec 15, 2006 at 01:06:08PM +0100, Albe Laurenz wrote:
> I guess that adding $EXTRA_LDAP_LIBS to -lldap_r will be enough,
> judging from the evidence on Linux.
Linux doesn't need the extra libraries, it's linked properly.
Additionally, on Linux there is no difference between ldap and ldap_
Olivier PRENANT wrote:
>> You left out the case where --enable_thread_safety is specified.
>> In that case, the frontend has to be linked with libldap_r.so
>> instead of libldap.so.
>
> Yes, this was on purpose, my goal is to try to make a second
> patch when...
>
>> Does libldap_r.so _not_ requi
Hi Albe,
Thanks for your remarks
On Fri, 15 Dec 2006, Albe Laurenz wrote:
> Date: Fri, 15 Dec 2006 09:54:13 +0100
> From: Albe Laurenz <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr, Tom Lane <[EMAIL PROTECTED]>
> Cc: pgsql-hackers list
> Subject: RE: [HACKERS] unixware a
> Here's the diff for configure.in that works for me.
I have a concern about this patch:
> if test "$enable_thread_safety" = yes; then
> # on some platforms ldap_r fails to link without PTHREAD_LIBS
> AC_CHECK_LIB(ldap_r, ldap_simple_bind, [],
> [AC_MSG_ERRO
ohp@pyrenet.fr writes:
> Here's the diff for configure.in that works for me.
Applied, thanks.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-n
t;-lldap $EXTRA_LDAP_LIBS"
fi
else
AC_CHECK_LIB(wldap32, ldap_bind, [], [AC_MSG_ERROR([library 'wldap32' is
required for LDAP])])
On Mon, 11 Dec 2006, Tom Lane wrote:
> Date: Mon, 11 Dec 2006 11:26:14 -0500
> From: Tom Lane <[EMAIL PROTECTED]>
> To:
Olivier PRENANT wrote:
>>> When I swithed to the newest version og pgbuildfarm, I noticed that
>>> --with-ldap (now by defaut) didn't work on UnixWare.
>>>
>>> This is because, on Unixware, ldap needs lber and resolv.
>>
>> Or was libldap not linked against liblber and libresolv?
>
> Dunno!
> Did'n
ohp@pyrenet.fr writes:
> I was in the process of testing this. But I believe tweaking with
> configure.in will not help me as I have no way to regenerate configure...
Install autoconf; it's no big deal.
regards, tom lane
---(end of broadcast)--
PROTECTED]>
> To: Albe Laurenz <[EMAIL PROTECTED]>
> Cc: ohp@pyrenet.fr, pgsql-hackers list
> Subject: Re: [HACKERS] unixware and --with-ldap
>
> "Albe Laurenz" <[EMAIL PROTECTED]> writes:
> > Shouldn't that be
> > AC_CHECK_LIB(ldap_r, ldap_
On Tue, 12 Dec 2006, Albe Laurenz wrote:
> Date: Tue, 12 Dec 2006 16:42:50 +0100
> From: Albe Laurenz <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr, pgsql-hackers list ,
> [EMAIL PROTECTED]
> Subject: RE: [HACKERS] unixware and --with-ldap
>
> Olivier PRENANT wrote:
On Tue, Dec 12, 2006 at 04:42:50PM +0100, Albe Laurenz wrote:
> Or do shared libraries on Unixware generally 'not remember'
> the libraries they were linked against (this would be strange).
It could be that whoever compiled libldap there did not include the
dependancies at link time. It is legal t
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Shouldn't that be
> AC_CHECK_LIB(ldap_r, ldap_simple_bind, [],
> [AC_MSG_ERROR([library 'ldap_r' is required for
> LDAP])],
> [$PTHREAD_LIBS $EXTRA_LDAP_LIBS])
Ooops, of course. Like I said, untested ;-)
Olivier PRENANT wrote:
> When I swithed to the newest version og pgbuildfarm, I noticed that
> --with-ldap (now by defaut) didn't work on UnixWare.
>
> This is because, on Unixware, ldap needs lber and resolv.
Is libldap a static library on that system?
Or do shared libraries on Unixware gener
an <[EMAIL PROTECTED]>
> Cc: ohp@pyrenet.fr, pgsql-hackers list
> Subject: Re: [HACKERS] unixware and --with-ldap
>
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > The right way to do this I think is to put an entry adjusting LIBS in
> > src/makefiles/Makefile.un
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The right way to do this I think is to put an entry adjusting LIBS in
> src/makefiles/Makefile.unixware, but first it looks like we need to
> propagate the with-ldap switch into src/Makefile.global
The Makefile is far too late --- this has to be adjus
ist
> Subject: Re: [HACKERS] unixware and --with-ldap
>
> ohp@pyrenet.fr wrote:
> > Hi all,
> >
> > When I swithed to the newest version og pgbuildfarm, I noticed that
> > --with-ldap (now by defaut) didn't work on UnixWare.
> >
> > This is because, on
ohp@pyrenet.fr wrote:
Hi all,
When I swithed to the newest version og pgbuildfarm, I noticed that
--with-ldap (now by defaut) didn't work on UnixWare.
This is because, on Unixware, ldap needs lber and resolv.
Not being a configure guru, I made the change bellow locally and that
works for me.
S
Hi all,
When I swithed to the newest version og pgbuildfarm, I noticed that
--with-ldap (now by defaut) didn't work on UnixWare.
This is because, on Unixware, ldap needs lber and resolv.
Not being a configure guru, I made the change bellow locally and that
works for me.
Surely, one of you hacker
[EMAIL PROTECTED] wrote:
> On Thu, 28 Oct 2004, Bruce Momjian wrote:
>
> > Date: Thu, 28 Oct 2004 19:58:56 -0400 (EDT)
> > From: Bruce Momjian <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: Tom Lane <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> &
On Thu, 28 Oct 2004, Bruce Momjian wrote:
> Date: Thu, 28 Oct 2004 19:58:56 -0400 (EDT)
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Tom Lane <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Unixware 714 pthreads
>
> [EM
[EMAIL PROTECTED] wrote:
> I agree with all that you say Tom, I'm just asking for some help to debug
> this, Now that Larry is a litle off the list, I'm feeling really lonely on
> UW.
> SCO won't do anything until I come up with a test program that fails. All
> my tries did work until then.
>
> I
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > On Thu, 28 Oct 2004, Tom Lane wrote:
> >> No. Why should the signal handler need re-arming?
>
> > My impression was that once caught, signal handler for a particular signal
> > is reset to SIG-DFL.
>
> No. If your signal support is POSIX-compatibl
gs like postfix or bind that nether fail.
I'm really at lost. Would you/someone help me?
Best regards
On Thu, 28 Oct 2004, Tom Lane wrote:
> Date: Thu, 28 Oct 2004 13:55:56 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Sub
[EMAIL PROTECTED] writes:
> On Thu, 28 Oct 2004, Tom Lane wrote:
>> No. Why should the signal handler need re-arming?
> My impression was that once caught, signal handler for a particular signal
> is reset to SIG-DFL.
No. If your signal support is POSIX-compatible, it should not do that
because
On Thu, 28 Oct 2004, Tom Lane wrote:
> Date: Thu, 28 Oct 2004 12:11:12 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Unixware 714 pthreads
>
> [EMAIL PROTECTED] writes:
> > if i do it a second
Tom Lane wrote:
[EMAIL PROTECTED] writes:
if i do it a second time in the same session, blockme() never returns
I wonder if handle_sig_alarm is re-armed after being used
No. Why should the signal handler need re-arming?
or if sleep is used anywhere in the backend.
Nope.
[EMAIL PROTECTED] writes:
> if i do it a second time in the same session, blockme() never returns
> I wonder if handle_sig_alarm is re-armed after being used
No. Why should the signal handler need re-arming?
> or if sleep is used anywhere in the backend.
Nope.
regards,
;
> TIA
> On Tue, 26 Oct 2004, Bruce Momjian wrote:
>
> > Date: Tue, 26 Oct 2004 17:59:17 -0400 (EDT)
> > From: Bruce Momjian <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [HACKERS] Unixware 714 pthreads
> &
On Wed, 27 Oct 2004, Bruce Momjian wrote:
> Date: Wed, 27 Oct 2004 14:53:26 -0400 (EDT)
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Unixware 714 pthreads
>
> [EMAIL PROTECTED] wrote:
> > De
[EMAIL PROTECTED] wrote:
> Dear Bruce,
>
> Thanks for your reply, I was desperate I did'nt get one!
>
> As I said, I'm quite sure there is a bug in pthread library, Before saying
> this to SCO, I have to prove it. Postgresql is the way to prove it!
>
> What I need is to know where to start from
wrote:
> Date: Tue, 26 Oct 2004 17:59:17 -0400 (EDT)
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Unixware 714 pthreads
>
>
> The only help I can be is that on Unixware (only) the backend is
> co
The only help I can be is that on Unixware (only) the backend is
compiled with threading enabled. This might be showing some thread
bugs.
---
[EMAIL PROTECTED] wrote:
> Hi every one,
>
> I need help to debug the problem I
Hi every one,
I need help to debug the problem I have on Unixware 714 and beta3.
postgresql make check hangs on plpgsql test when compiled with
--enable-thread-safty.
It does hang on select block_me();
This select should be canceled by the set statement_timeout=1000, instead,
the backend is 100%
--On Wednesday, May 12, 2004 22:14:33 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
I don't see a patch in here ... forget to attach it?
It was way back in the thread, and this was the upshot of the discussion.
See the note I just replied to Bruce with.
LER
--
Larry Rosenman
I don't see a patch in here ... forget to attach it?
On Wed, 12 May 2004, Larry Rosenman wrote:
> This is a re-post, and still the state of things.
>
> There were a few posts after this because of my STRENUOUS objection below.
>
> I still think we should enable threads somehow on this platform.
This is a re-post, and still the state of things.
There were a few posts after this because of my STRENUOUS objection below.
I still think we should enable threads somehow on this platform.
--On Monday, March 22, 2004 11:14:59 -0600 Larry Rosenman <[EMAIL PROTECTED]>
wrote:
--On Monday, Marc
--On Monday, March 22, 2004 13:15:15 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
--On Monday, March 22, 2004 12:49:00 -0500 Tom Lane
<[EMAIL PROTECTED]>=20 wrote:
If you can fix it yourself in a reasonably non-intrusive way, we'll take
the patch ... that
Larry Rosenman <[EMAIL PROTECTED]> writes:
> --On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <[EMAIL PROTECTED]>=20
> wrote:
>> If you can fix it yourself in a reasonably non-intrusive way, we'll take
>> the patch ... that's about the extent of the cooperation you can expect.
> would a dlsym-b
--On Monday, March 22, 2004 12:49:00 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
I really, really, really want to see threads enabled for libpq for this
platform, especially since SCO will be distributing it at some point in
time.
I think very few of the
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I really, really, really want to see threads enabled for libpq for this
> platform, especially since SCO will be distributing it at some point in
> time.
I think very few of the folks on this list will see that as a reason
why they should expend any eff
--On Monday, March 22, 2004 12:33:56 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> One other option is to disable threads on this platform for 7.5 unless
> we find another platforms that need this to use threads. That is the
> direction I will take for the moment. If
Larry Rosenman wrote:
> > One other option is to disable threads on this platform for 7.5 unless
> > we find another platforms that need this to use threads. That is the
> > direction I will take for the moment. If someone needs a threaded libpq
> > on this platform, then can enable threads, comp
--On Monday, March 22, 2004 09:52:54 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Bruce Momjian wrote:
Larry Rosenman wrote:
> The a.out (not any library) should be linked with -Kpthread (not
> -lpthread).
> This will force libthread to be linked in the right order relative to
> libc, libC,
Bruce Momjian wrote:
> Larry Rosenman wrote:
> > The a.out (not any library) should be linked with -Kpthread (not
> > -lpthread).
> > This will force libthread to be linked in the right order relative to
> > libc, libC, networking libraries, etc.
> >
> > In other words, the entire application ei
Larry Rosenman wrote:
> The a.out (not any library) should be linked with -Kpthread (not
> -lpthread).
> This will force libthread to be linked in the right order relative to
> libc, libC, networking libraries, etc.
>
> In other words, the entire application either is or is not linked with
> thr
Larry Rosenman wrote:
> > I thought that once you include libpthread in libpq, that you don't have
> > to mention it again then you use libpq. Is your platform different
> > somehow in this regard?
> >
> > I seem to remember this problem with libcrypt and libpq. Is this the
> > same problem?
> >
--On Thursday, March 18, 2004 22:47:39 -0600 Larry Rosenman
<[EMAIL PROTECTED]> wrote:
--On Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
I see that initdb is just the first of many /bin programs to be
compiled, so if we have to add the thread lib, we will
--On Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
On Thu, 18 Mar 2004, Larry Rosenman wrote:
> I attempted(!) to compile up CVS Head, and if you
> --enable-thread-safety, you need to include the THREADS stuff to cc:
>
> gmake[4]: Leavin
Larry Rosenman wrote:
> On Thu, 18 Mar 2004, Larry Rosenman wrote:
>
> > I attempted(!) to compile up CVS Head, and if you --enable-thread-safety,
> > you need to include the THREADS stuff to cc:
> >
> > gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port'
> > cc -O -Kinline initdb.o -L..
Larry Rosenman <[EMAIL PROTECTED]> writes:
> What is the concensus of the community?
AFAICS, initdb should not need to depend on libpq in the first place;
it never makes a connection to a live postmaster. I think it would be
cleaner to get rid of that dependency instead of propagating thread junk
--On Thursday, March 18, 2004 19:39:56 -0500 Tom Lane <[EMAIL PROTECTED]>
wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
What is the concensus of the community?
AFAICS, initdb should not need to depend on libpq in the first place;
it never makes a connection to a live postmaster. I think it
On Thu, 18 Mar 2004, Larry Rosenman wrote:
> I attempted(!) to compile up CVS Head, and if you --enable-thread-safety,
> you need to include the THREADS stuff to cc:
>
> gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port'
> cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq
> -
I attempted(!) to compile up CVS Head, and if you --enable-thread-safety,
you need to include the THREADS stuff to cc:
gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port'
cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq
-L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/
[ I have retained the original email below so people can remember where
we left this.]
After much agonizing, I have applied a patch to attempt threading in
this order:
use non-*_r function names if they are all thread-safe
(NEED_REENTRANT_FUNCS=no)
use *_r functions if they
On Wed, 10 Sep 2003 02:39 pm, Tom Lane wrote:
> A thread-safe implementation of
> libpq is of zero value to an application unless it also has thread-safe
> implementations of the other libraries it depends on.
Not necessarily so - we've managed okay so far (several years) working on
platforms t
Philip Yarra <[EMAIL PROTECTED]> writes:
> On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
>
> This would be a pretty short list unless I count wrong! This excludes all
> releases of FreeBSD (and I'm willing to bet other BSDs), Solaris (at least
> the old version I have), OSF, Linux, and who
Philip Yarra <[EMAIL PROTECTED]> writes:
> On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> It doesn't seem to me that we should take on the job of providing
>>> thread-safe implementations of basic libc functions. If a particular
>>> OS cannot manage to offer that functio
On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
> Tom Lane wrote:
> > It doesn't seem to me that we should take on the job of providing
> > thread-safe implementations of basic libc functions. If a particular
> > OS cannot manage to offer that functionality, then we should mark it
> > not-threa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tripple-yuck. :-)
>
> It doesn't seem to me that we should take on the job of providing
> thread-safe implementations of basic libc functions. If a particular
> OS cannot manage to offer that functionality, then we should mark it
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tripple-yuck. :-)
>
> It doesn't seem to me that we should take on the job of providing
> thread-safe implementations of basic libc functions. If a particular
> OS cannot manage to offer that functionality, then we should mark it
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tripple-yuck. :-)
It doesn't seem to me that we should take on the job of providing
thread-safe implementations of basic libc functions. If a particular
OS cannot manage to offer that functionality, then we should mark it
not-thread-safe and move on.
On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote:
> --- anyway, it is probably threadsafe, but strerror isn't, so we are
> dead anyway. :-)
Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when
everything else is... maybe Strange is OSF's middle name.
> > #ifdef SOME_DEF (sor
Philip Yarra wrote:
> On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> > I see --- looks bad failures below for OSF, Solaris, and FreeBSD
> > below.
>
> Actually, I am not sure the OSF failure is correctly reported... your test app
> had me a little baffled in that case.
Baffler is my m
On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> I see --- looks bad failures below for OSF, Solaris, and FreeBSD
> below.
Actually, I am not sure the OSF failure is correctly reported... your test app
had me a little baffled in that case.
> We would have to get some thread mutex, make
Philip Yarra wrote:
> On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
>
> Okay, here's results from the machines I have access to... I think what you're
> going to find is th
On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> I would like every operating system that supports thread-safety to run
> this program and report back the results.
Okay, here's results from the machines I have access to... I think what you're
going to find is that an awful lot of platforms tha
On Sun, 7 Sep 2003, Larry Rosenman wrote:
>
>
> --On Sunday, September 07, 2003 12:52:18 -0700 Stephan Szabo
> <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sun, 7 Sep 2003, Larry Rosenman wrote:
> >
> >>
> >>
> >> --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
> >>
> >> [snip]
--On Sunday, September 07, 2003 12:52:18 -0700 Stephan Szabo
<[EMAIL PROTECTED]> wrote:
On Sun, 7 Sep 2003, Larry Rosenman wrote:
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
> /usr/local/bin/gmake -C libpq all
> gmake[3]: Entering directory `/home/postgre
On Sun, 7 Sep 2003, Larry Rosenman wrote:
>
>
> --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
>
> [snip]
>
> > /usr/local/bin/gmake -C libpq all
> > gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
> > cc -O -Kinline,no_host -I../../../src/include -I
--On Sunday, September 07, 2003 14:19:00 -0500 Larry Rosenman
<[EMAIL PROTECTED]> wrote:
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
/usr/local/bin/gmake -C libpq all
gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
cc -O -Kinline,no_h
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
/usr/local/bin/gmake -C libpq all
gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o
ip.o ip.c UX:acomp: ERROR: "ip.c", lin
Hi,
I have those errors on Unixware 713 with yesterday and today's CVS
Script started on Sun Sep 7 20:19:16 2003
$ make
Using GNU make found at /usr/local/bin/gmake
/usr/local/bin/gmake -C doc all
gmake[1]: Entering directory `/home/postgres/pgsql/doc'
gmake[1]: Nothing to be done for `all'.
gmak
Can you pass me what's in CVS (anon hasn't updated afaict).
And, what didn't you like about my version?
LER
--On Wednesday, September 03, 2003 18:35:44 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> > What does your OS want for the 3rd argument of pthread_create()? I
Kurt Roeckx wrote:
> On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
> >
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
>
> On a Linux system with glibc 2.1:
> Your gethostbyname() is _not_ thread-safe
> Your
Larry Rosenman wrote:
> >> > What does your OS want for the 3rd argument of pthread_create()? I
> >> > thought a void pointer would be OK for everyone:
> >> >
> >> > pthread_create(&thread1, NULL, (void *) func_call_1, NULL);
> >>
> >> void *(*start_routine)(void*)
> >>
> >> Here is our man p
Larry Rosenman wrote:
> >From UnixWare:
>
> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with
> prototype: pthread_create()
> UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with
> prot
[EMAIL PROTECTED] wrote:
> FWIW, I do confirm, on dual XEON with JT enabled
Operating system?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your
[EMAIL PROTECTED] wrote:
> FWIW, I do confirm, on dual XEON with JT enabled
Oh, I now see OS as Unixware:
> I have 2 bi-pro machines here both running unixware
> 7.1.3 I can make tests if you want
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible
with prototype: pthread_create(
Larry Rosenman wrote:
>
>
> --On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > Larry Rosenman wrote:
> >> > From UnixWare:
> >>
> >> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> >> UX:acomp: WARNING: "test_thread.c", line 60: ar
--On Wednesday, September 03, 2003 17:09:49 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Larry Rosenman wrote:
>> > From UnixWare:
>>
>> $ cc -O -Kpthread test_thread.c -o test
On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
>
> I would like every operating system that supports thread-safety to run
> this program and report back the results.
On a Linux system with glibc 2.1:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Yo
FWIW, I do confirm, on dual XEON with JT enabled
On Wed, 3 Sep 2003, Larry Rosenman wrote:
> Date: Wed, 03 Sep 2003 14:53:39 -0500
> From: Larry Rosenman <[EMAIL PROTECTED]>
> To: Bruce Momjian <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: R
From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with
prototype: pthread_create()
UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with
prototype: pthread_create()
$ ./test_threa
[EMAIL PROTECTED] wrote:
> > Olivier PRENANT wrote:
> > > >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
> > > >> asked the threads guys, and he said that the libc stuff is
> > > >> thread-safe so they don't have to have 2 different versions in libc.
> > > >
> > > If any o
--On Wednesday, September 03, 2003 14:00:55 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> > Woh, I thought we just agreed that getpwuid_r() isn't required for
>> > thread-safety on your platform.
>> it's CLEANER to use it.
>>
>> Our API Signature is the _r version, why
MAIL PROTECTED]
> Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled
> ...)
>
> Olivier PRENANT wrote:
> > >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
> > >> asked the threads guys, and he said that
1 - 100 of 191 matches
Mail list logo
