RE: [HACKERS] Threads
От | Magnus Hagander |
---|---|
Тема | RE: [HACKERS] Threads |
Дата | |
Msg-id | 215896B6B5E1CF11BC5600805FFEA82101F70BF3@sirius.edu.sollentuna.se обсуждение исходный текст |
Список | pgsql-hackers |
> > > 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
В списке pgsql-hackers по дате отправления: