VC2005 build and pthreads
Folks,
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..
Regards,
Gevik
On Fri, Jan 26, 2007 at 09:34:10PM +0100, Gevik Babakhani wrote:
Folks,
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..
Err, pthreads is a threads library for Unix, I don't think Windows has
that, nor can I think of a situation where you'd need to worry about
threads anyway?
Have a nice day.
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
pthreads in needed to buold PG in vc++ 2005
please read pgsql/src/tools/msvc/README
Have a nice day.
Show quoted text
On Fri, 2007-01-26 at 21:47 +0100, Martijn van Oosterhout wrote:
On Fri, Jan 26, 2007 at 09:34:10PM +0100, Gevik Babakhani wrote:
Folks,
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..Err, pthreads is a threads library for Unix, I don't think Windows has
that, nor can I think of a situation where you'd need to worry about
threads anyway?Have a nice day.
Martijn van Oosterhout wrote:
On Fri, Jan 26, 2007 at 09:34:10PM +0100, Gevik Babakhani wrote:
Folks,
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..Err, pthreads is a threads library for Unix, I don't think Windows has
that, nor can I think of a situation where you'd need to worry about
threads anyway?
There is a pthreads for win32 as well.
However, you don't need it to build, unless you build ecpg. I forgot to
update the README when I put that patch in .-)
If you want it, it's on ftp://sources.redhat.com/pub/pthreads-win32.
IIRC, that's actually mentioned in the README file. You need the lib and
headers.
//Magnus
On Fri, Jan 26, 2007 at 10:10:20PM +0100, Magnus Hagander wrote:
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..
Err, pthreads is a threads library for Unix, I don't think Windows has
that, nor can I think of a situation where you'd need to worry about
threads anyway?
There is a pthreads for win32 as well.
However, you don't need it to build, unless you build ecpg. I forgot to
update the README when I put that patch in .-)
Actually you can build ecpg without pthreads as well, but you lose
thread-safety. The problem is that ecpg and libpq do different things on
Windows if you define ENABLE_THREAD_SAFETY.
ENABLE_THREAD_SAFETY is set to 1 in pg_config.h.win32, with it being
defined, ecpg needs the pthreads libraries, while libpq uses the stub
functions from pthread-win32.c. Libpq can do that because it doesn't use
pthread_(get|set)specific. If we implemented those functions by means of the
native Windows API as well, they could also be used by ecpg and we would not
need the pthread libs on Windows anymore.
Magnus, can we? ;-)
Joachim
Joachim Wieland wrote:
On Fri, Jan 26, 2007 at 10:10:20PM +0100, Magnus Hagander wrote:
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..Err, pthreads is a threads library for Unix, I don't think Windows has
that, nor can I think of a situation where you'd need to worry about
threads anyway?There is a pthreads for win32 as well.
However, you don't need it to build, unless you build ecpg. I forgot to
update the README when I put that patch in .-)Actually you can build ecpg without pthreads as well, but you lose
thread-safety. The problem is that ecpg and libpq do different things on
Windows if you define ENABLE_THREAD_SAFETY.ENABLE_THREAD_SAFETY is set to 1 in pg_config.h.win32, with it being
defined, ecpg needs the pthreads libraries, while libpq uses the stub
functions from pthread-win32.c. Libpq can do that because it doesn't use
pthread_(get|set)specific. If we implemented those functions by means of the
native Windows API as well, they could also be used by ecpg and we would not
need the pthread libs on Windows anymore.Magnus, can we? ;-)
Absolutely, I'll be happy to test your patch :)
Anyway. We hard-code thread-safety to on for Win32, because win32 is a
threaded platform in general - almost everything can be exposed to
threading even if they don't want it. For example a VB program that has
no threading at all can still run with multiple threads because of the
framework.
//Magnus
On Sun, Jan 28, 2007 at 02:05:41PM +0100, Magnus Hagander wrote:
Anyway. We hard-code thread-safety to on for Win32, because win32 is a
threaded platform in general - almost everything can be exposed to
threading even if they don't want it. For example a VB program that has
no threading at all can still run with multiple threads because of the
framework.
It'd be nice if we could do the same for some Unix platofrms like
Linux. The C library uses threads internally, and there's no actual
downside to enabling thread safety there, except removing a few failure
modes.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sun, Jan 28, 2007 at 02:05:41PM +0100, Magnus Hagander wrote:
Anyway. We hard-code thread-safety to on for Win32, because win32 is a
threaded platform in general - almost everything can be exposed to
threading even if they don't want it. For example a VB program that has
no threading at all can still run with multiple threads because of the
framework.It'd be nice if we could do the same for some Unix platofrms like
Linux. The C library uses threads internally, and there's no actual
downside to enabling thread safety there, except removing a few failure
modes.
I was not aware this was true on Linux.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Martijn van Oosterhout wrote:
It'd be nice if we could do the same for some Unix platofrms like
Linux. The C library uses threads internally, and there's no actual
downside to enabling thread safety there, except removing a few failure
modes.I was not aware this was true on Linux.
It uses threads at least for the POSIX AIO calls--I'm not sure what
else.
-Doug
Douglas McNaught <doug@mcnaught.org> writes:
Bruce Momjian <bruce@momjian.us> writes:
Martijn van Oosterhout wrote:
It'd be nice if we could do the same for some Unix platofrms like
Linux. The C library uses threads internally, and there's no actual
downside to enabling thread safety there, except removing a few failure
modes.I was not aware this was true on Linux.
It uses threads at least for the POSIX AIO calls--I'm not sure what
else.
I think the real point is that you get the same C library whether you
ask for thread safety or not, and it does internal locking to protect
itself against multi threads anyway. So arguably there's no point in
building a thread-unsafe version of libpq.
But having said that, 99.99% of Linux use is based on pre-built RPMs,
and the RPM packagers all understand how to make this decision, so
it's really not our problem to fix.
regards, tom lane
"Douglas McNaught" <doug@mcnaught.org> writes:
It uses threads at least for the POSIX AIO calls--I'm not sure what
else.
On that tangent, is that still true or is it only for older kernels that it's
true? I was under the impression newer kernels implemented the aio interface
but others seem to think it's not the case and glibc still emulates it with
threads. Looking up the truth of the situation has been on my mental todo list
for a while.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
On Mon, Feb 05, 2007 at 11:09:06AM -0500, Tom Lane wrote:
I think the real point is that you get the same C library whether you
ask for thread safety or not, and it does internal locking to protect
itself against multi threads anyway. So arguably there's no point in
building a thread-unsafe version of libpq.
The underlying issue is that there is no way to be sure a program will
not have threads. Just because you didn't compile against pthreads,
don't mean there won't be any threads. An example being a
gethostbyname() that loads a threaded version of an LDAP library, for
example.
For programs it doesn't matter, but for shared-libraries you never know
whether you're going to be called from the main thread of execution or
not, and if you're not you're buggered.
But having said that, 99.99% of Linux use is based on pre-built RPMs,
and the RPM packagers all understand how to make this decision, so
it's really not our problem to fix.
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the problem far outweigh the cost of the switch.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout <kleptog@svana.org> writes:
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the problem far outweigh the cost of the switch.
I'd vote against that unless it were done only for Linux, and personally
I think a platform-dependent default for this might be unreasonably
confusing.
regards, tom lane
On Mon, Feb 05, 2007 at 11:34:23AM -0500, Tom Lane wrote:
Martijn van Oosterhout <kleptog@svana.org> writes:
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the problem far outweigh the cost of the switch.I'd vote against that unless it were done only for Linux, and personally
I think a platform-dependent default for this might be unreasonably
confusing.
Well, it's already platform specific, Win32 removes the option
altogether (apparently). Which would be another option.
However, it only trips people up occasionally, so I'm not going to push
it.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout wrote:
On Mon, Feb 05, 2007 at 11:34:23AM -0500, Tom Lane wrote:
Martijn van Oosterhout <kleptog@svana.org> writes:
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the problem far outweigh the cost of the switch.I'd vote against that unless it were done only for Linux, and personally
I think a platform-dependent default for this might be unreasonably
confusing.Well, it's already platform specific, Win32 removes the option
altogether (apparently). Which would be another option.
Visual C build only, not the MingW build. It still has the option. The
win32 binary distribution sets it though.
//Magnus