You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dear folks, Thank you so much for providing and maintaining this repository! I am using it together with the libqp API to access a PostgreSQL database. According to libpq documentation I cannot issue concurrent commands from different threads through the same PGconn connection object. So, either I protect the PGconn connection object from concurrent calls from different threads like @babelouest mentioned in issue #263 or I use a dedicated PGconn connection object for each and every client thread. In #263@babelouest also mentioned that every client receives a dedicated thread as long as the default configuration of libmicrohttpd is not altered.
My question: Securing the single PGconn connection object with something like a Mutex does introduce latency to the system for waiting until the protected resource is available again. I could avoid latency if I provide a dedicated PGconn connection object to every client thread. Is that possible?
My second question: I could provide a dedicated PGconn connection object to the callback function of an API endpoint using the user_data parameter of the ulfius_add_endpoint_by_value function. However, this is not solving this issue. Two different client thread calling the same endpoint would use the same PGconn connection object. I could create the PGconn connection object inside the callback_function parameter. However, this introdues latency as a PGconn connection object is created for each and every client request. Is this reasoning correct?
Appreciate!
Cheers!
The text was updated successfully, but these errors were encountered:
In my experience, a mutex is the best way to ensure the stability, but I don't program with the intention to provide a highly performant solution, so this may not be the best way for your needs.
The way I see it, you can try different approaches:
Use one thread per connection in Ulfius
Use a single PGConn object, protected by a mutex or a similar mechanism
Use a pool of PGConn objects, one per CPU/Thread and protect them with a mechanism (i.e. mutexes, signals) to avoid deadlocks
I also suggest to open a discussion rather than an issue for these kind of questions. The discussions are a better format for interaction and feedbacks.
Dear folks, Thank you so much for providing and maintaining this repository! I am using it together with the
libqp
API to access a PostgreSQL database. According to libpq documentation I cannot issue concurrent commands from different threads through the samePGconn
connection object. So, either I protect thePGconn
connection object from concurrent calls from different threads like @babelouest mentioned in issue #263 or I use a dedicatedPGconn
connection object for each and every client thread. In #263 @babelouest also mentioned that every client receives a dedicated thread as long as the default configuration oflibmicrohttpd
is not altered.My question: Securing the single
PGconn
connection object with something like a Mutex does introduce latency to the system for waiting until the protected resource is available again. I could avoid latency if I provide a dedicatedPGconn
connection object to every client thread. Is that possible?My second question: I could provide a dedicated
PGconn
connection object to the callback function of an API endpoint using theuser_data
parameter of the ulfius_add_endpoint_by_value function. However, this is not solving this issue. Two different client thread calling the same endpoint would use the samePGconn
connection object. I could create thePGconn
connection object inside thecallback_function
parameter. However, this introdues latency as aPGconn
connection object is created for each and every client request. Is this reasoning correct?Appreciate!
Cheers!
The text was updated successfully, but these errors were encountered: