Re: [pgsql-www] NuSphere and PostgreSQL for windows

Hi there,

I got message from nusphere.com about windows port of PostgreSQL.
They're looking for full time developer in Russia,Moscow.

Is this is a joke ?

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

From the folks who brought you lawsuits with mysql... If it is true it
is the first I have heard of it. While I don't see why it couldn't be
true (as nusphere did market a mysql database at one time) it seems a
little odd since this would be pretty direct competition with their
parent company, Progress Software. The other odd part being that they
are looking for a developer in Moscow, I didn't know they had offices in
Russia and I don't see mention of any on thier website.

Oleg, depending on the confidentially level of the letter (given that
some core members work for would be direct competitors), could you
forward it to this list or perhaps some of us directly? I'm sure
Josh/myself would like to take a look, it could have interesting
ramifications from an advocacy point-of-view.

Robert Treat

On Fri, 2003-09-19 at 06:51, Oleg Bartunov wrote:
> Hi there,
>
> I got message from nusphere.com about windows port of PostgreSQL.
> They're looking for full time developer in Russia,Moscow.
>
> Is this is a joke ?
>
> Regards,
> Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83

--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Fri, 19 Sep 2003, Robert Treat wrote:

> From the folks who brought you lawsuits with mysql... If it is true it
> is the first I have heard of it. While I don't see why it couldn't be
> true (as nusphere did market a mysql database at one time) it seems a
> little odd since this would be pretty direct competition with their
> parent company, Progress Software. The other odd part being that they
> are looking for a developer in Moscow, I didn't know they had offices in
> Russia and I don't see mention of any on thier website.

Ummmm ... wasn't Peer Direct a child company of Progress? NuSphere was
their MySQL "division", and Peer Direct was their "PostgreSQL"?
Basically, put both hands in the pie and hope one comes out with some
fruit?

Robert,

On Fri, 19 Sep 2003, Robert Treat wrote:

> >From the folks who brought you lawsuits with mysql... If it is true it
> is the first I have heard of it. While I don't see why it couldn't be
> true (as nusphere did market a mysql database at one time) it seems a
> little odd since this would be pretty direct competition with their
> parent company, Progress Software. The other odd part being that they
> are looking for a developer in Moscow, I didn't know they had offices in
> Russia and I don't see mention of any on thier website.
>
> Oleg, depending on the confidentially level of the letter (given that
> some core members work for would be direct competitors), could you
> forward it to this list or perhaps some of us directly? I'm sure
> Josh/myself would like to take a look, it could have interesting
> ramifications from an advocacy point-of-view.

there is nothing to add, except the company was mentioned as
NuSphere (PeerDirect) and From: field was nusphere.com. It's interesting
that the message was sent to me and Teodor Sigaev. I recall,
a year ago I got message from one russian developer about something like
GiST for MySQL. He is the author of UdmSearch (MnogoSearch).

>
> Robert Treat
>
> On Fri, 2003-09-19 at 06:51, Oleg Bartunov wrote:
> > Hi there,
> >
> > I got message from nusphere.com about windows port of PostgreSQL.
> > They're looking for full time developer in Russia,Moscow.
> >
> > Is this is a joke ?
> >
> > Regards,
> > Oleg
> > _____________________________________________________________
> > Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> > Sternberg Astronomical Institute, Moscow University (Russia)
> > Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
> > phone: +007(095)939-16-83, +007(095)939-23-83
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> I got message from nusphere.com about windows port of PostgreSQL.
> They're looking for full time developer in Russia,Moscow.

> Is this is a joke ?

No, I expect they're serious. NuSphere does still own the PeerDirect
windows port that Jan worked on at his former job. They need someone
to maintain that and bring it forward to newer versions of PG. It's
not going to be a long-term product (assuming that we ever finish the
community's native port), so they need to keep the costs down. I'm
not surprised that they'd be looking to send the development overseas
instead of keeping it at their US offices.

regards, tom lane

On Fri, 19 Sep 2003, Tom Lane wrote:

> Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> > I got message from nusphere.com about windows port of PostgreSQL.
> > They're looking for full time developer in Russia,Moscow.
>
> > Is this is a joke ?
>
> No, I expect they're serious. NuSphere does still own the PeerDirect
> windows port that Jan worked on at his former job. They need someone
> to maintain that and bring it forward to newer versions of PG. It's
> not going to be a long-term product (assuming that we ever finish the
> community's native port), so they need to keep the costs down. I'm
> not surprised that they'd be looking to send the development overseas
> instead of keeping it at their US offices.

Hmm, I suspect they have some developers here in Russia. At least full text
search resembles me MnogoSearch. Anyway, I'm not willing to work with them.
Postgres forever

>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

On Fri, 2003-09-19 at 12:31, Oleg Bartunov wrote:
> On Fri, 19 Sep 2003, Tom Lane wrote:
>
> > Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> > > I got message from nusphere.com about windows port of PostgreSQL.
> > > They're looking for full time developer in Russia,Moscow.
> >
> > > Is this is a joke ?
> >
> > No, I expect they're serious. NuSphere does still own the PeerDirect
> > windows port that Jan worked on at his former job. They need someone
> > to maintain that and bring it forward to newer versions of PG. It's
> > not going to be a long-term product (assuming that we ever finish the
> > community's native port), so they need to keep the costs down. I'm
> > not surprised that they'd be looking to send the development overseas
> > instead of keeping it at their US offices.
>
> Hmm, I suspect they have some developers here in Russia. At least full text
> search resembles me MnogoSearch. Anyway, I'm not willing to work with them.
> Postgres forever
>

Don't be too hasty. I don't know about anyone else, but I'd welcome an
updated commercial native windows solution (When's SRA's port coming out
in 1.0?) , especially if they'd be willing to provide a "diff" of the
code back to the community. We might as well have someone get paid for
work we will probably have to do anyways...

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

On Fri, 19 Sep 2003, Robert Treat wrote:

> On Fri, 2003-09-19 at 12:31, Oleg Bartunov wrote:
> > On Fri, 19 Sep 2003, Tom Lane wrote:
> >
> > > Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> > > > I got message from nusphere.com about windows port of PostgreSQL.
> > > > They're looking for full time developer in Russia,Moscow.
> > >
> > > > Is this is a joke ?
> > >
> > > No, I expect they're serious. NuSphere does still own the PeerDirect
> > > windows port that Jan worked on at his former job. They need someone
> > > to maintain that and bring it forward to newer versions of PG. It's
> > > not going to be a long-term product (assuming that we ever finish the
> > > community's native port), so they need to keep the costs down. I'm
> > > not surprised that they'd be looking to send the development overseas
> > > instead of keeping it at their US offices.
> >
> > Hmm, I suspect they have some developers here in Russia. At least full text
> > search resembles me MnogoSearch. Anyway, I'm not willing to work with them.
> > Postgres forever
> >
>
> Don't be too hasty. I don't know about anyone else, but I'd welcome an
> updated commercial native windows solution (When's SRA's port coming out
> in 1.0?) , especially if they'd be willing to provide a "diff" of the
> code back to the community. We might as well have someone get paid for
> work we will probably have to do anyways...

I think a few things that Oleg needs to find out first is whether or not
PeerDirect *will* feed it back to the community ... how much did they feed
back of Jan's work? Considering where win32 seems to be sitting, it
doesn't seem like much ...

Oleg Bartunov wrote:
> > >From the folks who brought you lawsuits with mysql... If it is true it
> > is the first I have heard of it. While I don't see why it couldn't be
> > true (as nusphere did market a mysql database at one time) it seems a
> > little odd since this would be pretty direct competition with their
> > parent company, Progress Software. The other odd part being that they
> > are looking for a developer in Moscow, I didn't know they had offices in
> > Russia and I don't see mention of any on thier website.
> >
> > Oleg, depending on the confidentially level of the letter (given that
> > some core members work for would be direct competitors), could you
> > forward it to this list or perhaps some of us directly? I'm sure
> > Josh/myself would like to take a look, it could have interesting
> > ramifications from an advocacy point-of-view.
>
> there is nothing to add, except the company was mentioned as
> NuSphere (PeerDirect) and From: field was nusphere.com. It's interesting
> that the message was sent to me and Teodor Sigaev. I recall,
> a year ago I got message from one russian developer about something like
> GiST for MySQL. He is the author of UdmSearch (MnogoSearch).

I can confirm that Nusphere still has a division in Russia, and they
need PostgreSQL assistance, perhaps for the replication part of
PeerDirect.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Robert Treat wrote:
> > Hmm, I suspect they have some developers here in Russia. At least full text
> > search resembles me MnogoSearch. Anyway, I'm not willing to work with them.
> > Postgres forever
> >
>
> Don't be too hasty. I don't know about anyone else, but I'd welcome an
> updated commercial native windows solution (When's SRA's port coming out
> in 1.0?) , especially if they'd be willing to provide a "diff" of the
> code back to the community. We might as well have someone get paid for
> work we will probably have to do anyways...

SRA's Windows port is up to 7.3.4, and I think they just released
version 1.1, so that is going fine --- and I have the source code to
use in our native Win32 port, just not the threading stuff.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Marc G. Fournier wrote:
> > Don't be too hasty. I don't know about anyone else, but I'd welcome an
> > updated commercial native windows solution (When's SRA's port coming out
> > in 1.0?) , especially if they'd be willing to provide a "diff" of the
> > code back to the community. We might as well have someone get paid for
> > work we will probably have to do anyways...
>
> I think a few things that Oleg needs to find out first is whether or not
> PeerDirect *will* feed it back to the community ... how much did they feed
> back of Jan's work? Considering where win32 seems to be sitting, it
> doesn't seem like much ...

PeerDirect contributed the code, but neither they or Jan wanted to port
it up to current CVS, and that's were we/I got stuck.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > > Don't be too hasty. I don't know about anyone else, but I'd welcome an
> > > updated commercial native windows solution (When's SRA's port coming out
> > > in 1.0?) , especially if they'd be willing to provide a "diff" of the
> > > code back to the community. We might as well have someone get paid for
> > > work we will probably have to do anyways...
> >
> > I think a few things that Oleg needs to find out first is whether or not
> > PeerDirect *will* feed it back to the community ... how much did they feed
> > back of Jan's work? Considering where win32 seems to be sitting, it
> > doesn't seem like much ...
>
> PeerDirect contributed the code, but neither they or Jan wanted to port
> it up to current CVS, and that's were we/I got stuck.
>

So it would be a boon for them to pay someone to bring it up to date
(assuming they would donate it back to the community).

> SRA's Windows port is up to 7.3.4, and I think they just released
> version 1.1, so that is going fine --- and I have the source code to
> use in our native Win32 port, just not the threading stuff.

And if I've paid attention, the threading bits are what SRA used to get
around the fork/exec issues?

Incidentally I don't recall any announcements from SRA that they were
past the beta development phase with their version, seems like that
could have gotten some mention on the main postgresql site.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
> On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
>> SRA's Windows port is up to 7.3.4, and I think they just released
>> version 1.1, so that is going fine --- and I have the source code to
>> use in our native Win32 port, just not the threading stuff.

> And if I've paid attention, the threading bits are what SRA used to get
> around the fork/exec issues?

BTW, I've been wondering lately if we'd not be better off to look at
using threading in the Windows port, if it'd help us get around the
fork/exec data transfer problem. I'm not sure that it would, mind you,
but if it would give an answer it might be a lot less painful than
solving the data transfer problem directly.

Our main objections to threading in the past have always been lack of
portability and loss of robustness. Portability isn't an issue for a
Windows-only solution, and I'm not too concerned about the other either,
since I'll never think that Windows would be a place to run a production
server anyway.

regards, tom lane

Tom Lane wrote:

>Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
>
>
>>On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
>>
>>
>>>SRA's Windows port is up to 7.3.4, and I think they just released
>>>version 1.1, so that is going fine --- and I have the source code to
>>>use in our native Win32 port, just not the threading stuff.
>>>
>>>
>
>
>
>>And if I've paid attention, the threading bits are what SRA used to get
>>around the fork/exec issues?
>>
>>
>
>BTW, I've been wondering lately if we'd not be better off to look at
>using threading in the Windows port, if it'd help us get around the
>fork/exec data transfer problem. I'm not sure that it would, mind you,
>but if it would give an answer it might be a lot less painful than
>solving the data transfer problem directly.
>
When talking about threading in pgsql to Bruce on Linuxtag, he stated
that the main problem would be the tons of global variables used
throughout the backend. Killing global variables might give more
flexibility and coding robustness.

>Our main objections to threading in the past have always been lack of
>portability and loss of robustness.
>
MS SQL seems to have a mechanism that lets it kill faulty threads
without bringing down the whole process, however that works (I've seen
several crashes on a single connection, while the server process
continued to work). So the current advantage of dedicated backend
processes might be preservable with threading.

> Portability isn't an issue for a
>Windows-only solution, and I'm not too concerned about the other either,
>since I'll never think that Windows would be a place to run a production
>server anyway.
>
This sounds *very* naive. I'm quite sure that a lot of admins will use
the win32 pgsql for production use, because their corporation
infrastructure says "we run M$ servers", and thus only develepment and
testing machines have Linux running.

The win32 port is demanded and expected to give a boost to pgsql usage,
probably not caused by test machines only...

Regards,
Andreas

Tom Lane wrote:

> Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> writes:
>
>>On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
>>
>>>SRA's Windows port is up to 7.3.4, and I think they just released
>>>version 1.1, so that is going fine --- and I have the source code to
>>>use in our native Win32 port, just not the threading stuff.
>
>
>>And if I've paid attention, the threading bits are what SRA used to get
>>around the fork/exec issues?
>
>
> BTW, I've been wondering lately if we'd not be better off to look at
> using threading in the Windows port, if it'd help us get around the
> fork/exec data transfer problem. I'm not sure that it would, mind you,
> but if it would give an answer it might be a lot less painful than
> solving the data transfer problem directly.
>
> Our main objections to threading in the past have always been lack of
> portability and loss of robustness. Portability isn't an issue for a
> Windows-only solution, and I'm not too concerned about the other either,
> since I'll never think that Windows would be a place to run a production
> server anyway.

Assuming windows port would be built out of same code tree as that of unix
builds....

Considering this could be a configure time option, you mean to say that even on
Unix we could get threaded postgresql which would not require any shared buffers
but instead operate upon local shared buffers only?

Of course that would remain an option only. Old behaviour of process/shared
memory will still be there..

Do I understand this correctly? If abstraction work is going to be done, adding
thread-model specific could be just another layer.

So we have..

- Windows thread model
- pthreads on unix model
- Process+shared buffers model

And postgresql could work in either of the modes depending upon platform.

That would be good news. I am sure local buffers would be lot cheaper than
shared buffers.

Shridhar

Tom Lane wrote:

>BTW, I've been wondering lately if we'd not be better off to look at
>using threading in the Windows port, if it'd help us get around the
>fork/exec data transfer problem. I'm not sure that it would, mind you,
>but if it would give an answer it might be a lot less painful than
>solving the data transfer problem directly.
>

I am sure you are correct. The whole Windows API is more multi-thread
friendly than multi-process friendly, and operates far more efficiently
that way, as I understand it. There is also some potential benefit on
some *nix systems, where thread creation is far less costly than
forking, or at least this used to be the case last time I looked at it.

>
>Our main objections to threading in the past have always been lack of
>portability and loss of robustness. Portability isn't an issue for a
>Windows-only solution, and I'm not too concerned about the other either,
>since I'll never think that Windows would be a place to run a production
>server anyway.
>
>
>
Not that I like Windows all that much, but using it for a server is
becoming more defensible as an option. As for portability, what *nix is
there these days that doesn't have some sort of lightweight thread support?

Maybe the relevant parts of the system need to be abstracted out and
threading generally made a build time option (on by default for Windows,
off by default otherwise, maybe?)

cheers

andrew

Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
> Considering this could be a configure time option, you mean to say
> that even on Unix we could get threaded postgresql which would not
> require any shared buffers but instead operate upon local shared
> buffers only?

Only if we were prepared to support multiple, no doubt incompatible
threading libraries, which is exactly what I wasn't volunteering us for.

> I am sure local buffers would be lot cheaper than shared buffers.

On what do you base that? It sounds like pure fantasy to me. RAM is RAM.

regards, tom lane

Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> Tom Lane wrote:
>> BTW, I've been wondering lately if we'd not be better off to look at
>> using threading in the Windows port, if it'd help us get around the
>> fork/exec data transfer problem.

> When talking about threading in pgsql to Bruce on Linuxtag, he stated
> that the main problem would be the tons of global variables used
> throughout the backend.

Yeah, it would reverse the problem from "how to share data" to "how not
to share data". We'd want to find a way to ensure that the bulk of the
static data becomes per-thread data (or, in some cases, add a mutex so
that multiple threads can safely share one copy). It won't be a trivial
bit of work, but conceivably it could be less messy than trying to store
and reload many of those same variables.

regards, tom lane

Tom Lane wrote:

> Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
>
>>Considering this could be a configure time option, you mean to say
>>that even on Unix we could get threaded postgresql which would not
>>require any shared buffers but instead operate upon local shared
>>buffers only?
>
>
> Only if we were prepared to support multiple, no doubt incompatible
> threading libraries, which is exactly what I wasn't volunteering us for.

In my view, we have a advantage here. If we say that we would support a
reasonable pthreads implementation, that would be good enough, because we have a
working product in process model.

So we can let that platform catchup with threading model at it's own pace. Till
that time it can work in older model. We need not push really hard for platform
incompatible threading models like say mysql have to do.

The little pthreads programming I did on linux/freeBSD tells me that it supports
majority of features except TLS(linux2.4/linuxthreads) and per thread signals.
IIRC HP-UX supports pthreads as well and recommends moving to that threading
model. Solaris surely does support pthreads.

>>I am sure local buffers would be lot cheaper than shared buffers.
> On what do you base that? It sounds like pure fantasy to me. RAM is RAM.

For sure that is correct. But kernel interaction would matter. e.g. a linux
kernel without pre-emption/low latency and one with all those features would
certainly register speed and latency differences for heavily contended buffers.
The issue will be even more grave for small amount of buffers since they will be
contended more.

Its not about RAM. Its about how lightweight and/or efficient kernel
implementaion of shared memory and cross-process synchronisation object is.
Surely say linux and solaris are going to register differences..:-)

Shridhar

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
> > Considering this could be a configure time option, you mean to say
> > that even on Unix we could get threaded postgresql which would not
> > require any shared buffers but instead operate upon local shared
> > buffers only?
>
> Only if we were prepared to support multiple, no doubt incompatible
> threading libraries, which is exactly what I wasn't volunteering us for.

Well if you're only going to do one threading API you may as well pick the
POSIX standard. Windows threading is only useful for windows, POSIX threading
would work on every other OS, Solaris, Linux, BSD, etc.

Is there a POSIX threads wrapper for windows?

--
greg

Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:

> The little pthreads programming I did on linux/freeBSD tells me that it
> supports majority of features except TLS(linux2.4/linuxthreads) and per thread
> signals.

LinuxThreads is dead. NPTL is the way and the light.

It has ELF TLS which for super-fast thread-local storage, proper per-thread
signal semantics, as well as not using USR1,USR2 in ways that mess up
signal-handling. It also has kernel support for user-space mutexes (strange as
that may sound).

> >>I am sure local buffers would be lot cheaper than shared buffers.
> > On what do you base that? It sounds like pure fantasy to me. RAM is RAM.

Well that's not entirely true. Thread context switches don't involve MMU
operations the way process context switches do. So even though RAM is RAM, the
RAM in the threaded implementation might be faster to access simply because
it's already in the processor cache. The process model has to do a TLB flush
and load a whole new page table which takes a lot of time to begin with, and
then slows down all memory accesses later.

--
greg

Andrew Dunstan wrote:

> Tom Lane wrote:
>
>> BTW, I've been wondering lately if we'd not be better off to look at
>> using threading in the Windows port, if it'd help us get around the
>> fork/exec data transfer problem. I'm not sure that it would, mind you,
>> but if it would give an answer it might be a lot less painful than
>> solving the data transfer problem directly.
>>
>
> I am sure you are correct. The whole Windows API is more multi-thread
> friendly than multi-process friendly, and operates far more
> efficiently that way, as I understand it. There is also some potential
> benefit on some *nix systems, where thread creation is far less costly
> than forking, or at least this used to be the case last time I looked
> at it.
>
>>
>> Our main objections to threading in the past have always been lack of
>> portability and loss of robustness. Portability isn't an issue for a
>> Windows-only solution, and I'm not too concerned about the other either,
>> since I'll never think that Windows would be a place to run a production
>> server anyway.
>>
>>
>>
> Not that I like Windows all that much, but using it for a server is
> becoming more defensible as an option. As for portability, what *nix
> is there these days that doesn't have some sort of lightweight thread
> support?
>
> Maybe the relevant parts of the system need to be abstracted out and
> threading generally made a build time option (on by default for
> Windows, off by default otherwise, maybe?)

This seems to be the best option.
Whether a specific *ix application really benefits from threads or
suffers from this, should be evaluated on each platform. Having this
option is certainly advantageous.

BTW, this would lower the problems with memory over-commit: no forking,
no spare mem allocation needed, right?

Regards,
Andreas

On Fri, 26 Sep 2003 01:18 am, Greg Stark wrote:
> Well if you're only going to do one threading API you may as well pick the
> POSIX standard. Windows threading is only useful for windows, POSIX
> threading would work on every other OS, Solaris, Linux, BSD, etc.
>
> Is there a POSIX threads wrapper for windows?

Yes and no... there's no native POSIX thread wrapper, if that's what you mean
(say like pthreads on OSF wraps DECThreads AFAIK).

There's a development effort here (http://sources.redhat.com/pthreads-win32/)
to help those using Windows, but if it was me, I'd probably stick to native
Windows threads. It's not going to be on people's machines by default.

Regards, Philip.

Greg Stark wrote:

> Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
>
>
>>The little pthreads programming I did on linux/freeBSD tells me that it
>>supports majority of features except TLS(linux2.4/linuxthreads) and per thread
>>signals.
>
>
> LinuxThreads is dead. NPTL is the way and the light.
>
> It has ELF TLS which for super-fast thread-local storage, proper per-thread
> signal semantics, as well as not using USR1,USR2 in ways that mess up
> signal-handling. It also has kernel support for user-space mutexes (strange as
> that may sound).

Well.. Linuxthreads or NPTL, they are going to conform to pthreads standard
right? In fact NPTL is supposed to be better conformant than linuxthreads.

Shridhar

Robert Treat wrote:
> On Wed, 2003-09-24 at 13:11, Bruce Momjian wrote:
> > Marc G. Fournier wrote:
> > > > Don't be too hasty. I don't know about anyone else, but I'd welcome an
> > > > updated commercial native windows solution (When's SRA's port coming out
> > > > in 1.0?) , especially if they'd be willing to provide a "diff" of the
> > > > code back to the community. We might as well have someone get paid for
> > > > work we will probably have to do anyways...
> > >
> > > I think a few things that Oleg needs to find out first is whether or not
> > > PeerDirect *will* feed it back to the community ... how much did they feed
> > > back of Jan's work? Considering where win32 seems to be sitting, it
> > > doesn't seem like much ...
> >
> > PeerDirect contributed the code, but neither they or Jan wanted to port
> > it up to current CVS, and that's were we/I got stuck.
> >
>
> So it would be a boon for them to pay someone to bring it up to date
> (assuming they would donate it back to the community).
>
>
> > SRA's Windows port is up to 7.3.4, and I think they just released
> > version 1.1, so that is going fine --- and I have the source code to
> > use in our native Win32 port, just not the threading stuff.
>
> And if I've paid attention, the threading bits are what SRA used to get
> around the fork/exec issues?
>
> Incidentally I don't recall any announcements from SRA that they were
> past the beta development phase with their version, seems like that
> could have gotten some mention on the main postgresql site.

Here is SRA's News page, translated into English:

http://www.excite.co.jp/world/url/body/?wb_url=http%3A%2F%2Fosb.sra.co.jp&submit=%83E%83F%83u%83y%81%5B%83W%96%7C%96%F3&wb_lp=JAEN&wb_dis=2&wb_co=excitejapan

(Babelfish has problems, so I used Excite.) You can see the products
they have. I will post something to the PostgreSQL events list.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073