ecpg threading vs win32
This patch replaces the pthreads code in ecpg with native win32 threads,
in order to make it threadsafe. The idea is not to have to download the
non-standard pthreads library on windows.
Does it seem like it should be doing the right thing? Does somebody have
a good test-case where ecpg breaks when not built thread-safe? (which
would then also break when built thread-safe with a broken implementation)
//Magnus
Magnus Hagander <magnus@hagander.net> wrote:
This patch replaces the pthreads code in ecpg with native win32 threads,
in order to make it threadsafe. The idea is not to have to download the
non-standard pthreads library on windows.Does it seem like it should be doing the right thing? Does somebody have
a good test-case where ecpg breaks when not built thread-safe? (which
would then also break when built thread-safe with a broken implementation)
I have two questions about thread-safe ecpg.
Q1. Don't you use CRITICAL_SECTION instead of Mutex (CreateMutex)?
I've heard there is a performance benefit in CRITICAL_SECTION.
If the mutex is shared only in one process, CS might be a better solution.
http://japan.internet.com/developer/img/article/873/17801.gif
http://world.std.com/~jmhart/csmutx.htm
Q2. Do we need to use PQescapeStringConn() instead of PQescapeString()?
PQescapeString() is used to escape literals, and the documentation says
PQescapeStringConn() should be used in multi-threaded client programs.
http://momjian.us/main/writings/pgsql/sgml/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING
| PQescapeString can be used safely in single-threaded client programs
| that work with only one PostgreSQL connection at a time
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
On Mon, Mar 19, 2007 at 09:33:54AM +0900, ITAGAKI Takahiro wrote:
Magnus Hagander <magnus@hagander.net> wrote:
This patch replaces the pthreads code in ecpg with native win32 threads,
in order to make it threadsafe. The idea is not to have to download the
non-standard pthreads library on windows.Does it seem like it should be doing the right thing? Does somebody have
a good test-case where ecpg breaks when not built thread-safe? (which
would then also break when built thread-safe with a broken implementation)I have two questions about thread-safe ecpg.
Q1. Don't you use CRITICAL_SECTION instead of Mutex (CreateMutex)?
I've heard there is a performance benefit in CRITICAL_SECTION.
If the mutex is shared only in one process, CS might be a better solution.
http://japan.internet.com/developer/img/article/873/17801.gif
http://world.std.com/~jmhart/csmutx.htm
Yes, CS can be slightly faster. Though under this use-pattern, I think
it will not make a measurable difference at all.
The reason I went with Mutex is that I wanted it to be as similar as
possible to the pthreads code.
Q2. Do we need to use PQescapeStringConn() instead of PQescapeString()?
PQescapeString() is used to escape literals, and the documentation says
PQescapeStringConn() should be used in multi-threaded client programs.
http://momjian.us/main/writings/pgsql/sgml/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING
| PQescapeString can be used safely in single-threaded client programs
| that work with only one PostgreSQL connection at a time
Seems so, but that's unrelated to this patch ;-) I'll leave the final
comment on that up to Michael.
//Magnus
On Mon, Mar 19, 2007 at 09:48:19AM +0100, Magnus Hagander wrote:
Q2. Do we need to use PQescapeStringConn() instead of PQescapeString()?
PQescapeString() is used to escape literals, and the documentation says
PQescapeStringConn() should be used in multi-threaded client programs.
http://momjian.us/main/writings/pgsql/sgml/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING
| PQescapeString can be used safely in single-threaded client programs
| that work with only one PostgreSQL connection at a timeSeems so, but that's unrelated to this patch ;-) I'll leave the final
comment on that up to Michael.
Looking at the source code it seems to me that the connection argument
is only used once in PQescapeStringInternal which both functions call.
Here's the snippet:
if (conn)
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("incomplete multibyte character\n"));
So this essantially is only to get an error message into the connection
structure. However, having an empty connection makes PQescapeStringConn
return an error and an empty string which I consider a problem. I have
to check that in detail but we may run into a usage of
PQescapeString without an open connection which then would fail.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael, is there any progress on this?
---------------------------------------------------------------------------
Michael Meskes wrote:
On Mon, Mar 19, 2007 at 09:48:19AM +0100, Magnus Hagander wrote:
Q2. Do we need to use PQescapeStringConn() instead of PQescapeString()?
PQescapeString() is used to escape literals, and the documentation says
PQescapeStringConn() should be used in multi-threaded client programs.
http://momjian.us/main/writings/pgsql/sgml/libpq-exec.html#LIBPQ-EXEC-ESCAPE-STRING
| PQescapeString can be used safely in single-threaded client programs
| that work with only one PostgreSQL connection at a timeSeems so, but that's unrelated to this patch ;-) I'll leave the final
comment on that up to Michael.Looking at the source code it seems to me that the connection argument
is only used once in PQescapeStringInternal which both functions call.
Here's the snippet:if (conn)
printfPQExpBuffer(&conn->errorMessage,
libpq_gettext("incomplete multibyte character\n"));So this essantially is only to get an error message into the connection
structure. However, having an empty connection makes PQescapeStringConn
return an error and an empty string which I consider a problem. I have
to check that in detail but we may run into a usage of
PQescapeString without an open connection which then would fail.Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Mon, Apr 02, 2007 at 09:06:17PM -0400, Bruce Momjian wrote:
Michael, is there any progress on this?
---------------------------------------------------------------------------So this essantially is only to get an error message into the connection
structure. However, having an empty connection makes PQescapeStringConn
return an error and an empty string which I consider a problem. I have
to check that in detail but we may run into a usage of
PQescapeString without an open connection which then would fail.
Not really. IMO it should remain as it is.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!