> > > As well, a few have been asking about multi-threading.
> > > Any thoughts?
> >
> > Threads within a client backend might be interesting. [...]
>
> Hmm, what about threads in the frontend? Anyone know if libpq
> is thread
> safe, and if not, how hard it might be to make it so?
I beleive it is, as long as you only use each PGconn or PGresult from one
thread at a time. If you have two threads using the same PGconn, you're in
for trouble.
Making handling of PGresult thread-safe shouldn't be too hard, except you
have to do it platform-specific (you need some kind of mutex or similar, and
I doubt you can use the same code on e.g. any Unix and Win32).
Doing the same for PGconn is probably a lot harder, since the
frontend/backend protocol is "single threaded". So some kind of "tagging" of
each packet telling which thread it belongs to would be required. It would
probably be possible to "lock" the whole PGconn at the start of any
processing (such as sending a query), and then "unlock" once all the results
have been moved into a PGresult, but that is going to leave the PGconn
locked almost always, which kind of takes away the advantage of threading.
I think.
//Magnus