- server connect to the database and wait for incoming connections
- when incoming connection occurs, server request the database for some data about connected client - server must do it asynchronously and without creating any threads just for connected client (there can be more than thousand clients)
- at moment of requesting data from the database there already can be some active requests
- when database respond it is need to know for which client this data received (and what kind of request it was)
That's all.
P.S. it is possible to implement it requesting data one-by-one (adding each request to the queue and popping (FIFO) each request after each database' respond) but it is slow because it's need to wait data transferring through the net while database (server) itself will be idling.
[Did I figured out with some "cc"? Can I remove the commented previous letters in each respond?]
5 января 2011 г. 23:10 пользователь Peter Geoghegan <peter.geoghegan86@xxxxxxxxx> написал:
2011/1/5 Вячеслав Блинников <slavmfm@xxxxxxxxx>:
You cannot "bind" data to a query. You cannot execute two queries in> Database connection using "libpq":
> So, generally speaking, I need:
> - send multiple queries using "PQsendQuery()" (or what else)
> - bind some data (void*) to each qeury
> - obtain results using "PQgetResult()" (or what else) and to know which data
> is bound to each result (correspondence between queries and results)
> How it can be implemented?
parallel with one connection. However, PGresults exist totally
independently or the connection or thread that originated them, so
feel free to stash them as you see fit.
libpq usually operates within the same thread context as the client
application, so in general it doesn't make sense to pass a function
pointer (which you suggested in a slightly earlier mail to the list)
that will be called back asynchronously like a signal handler.
Asynchronous command processing just exists as a way to keep a GUI
responsive and things like that, because PQExec() blocks.
Maybe it would help if you stepped back and described your problem in
broader terms.
--
Regards,
Peter Geoghegan
