Thread: 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/ > 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. 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/ > 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/ > 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/ > 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