Thanks for your feedback, indeed postgres has a nonblocking interface, but in this case, this code is part of a freeradius module, the threads are created by freeradius (not me) and are out of my control. Those freeradius threads will use the functions in my module each time a new AAA request comes in. So, for example, an accounting request comes in to the server, one of the freeradius thread will start iterating over the internal modules queue in the radius calling all modules function for accounting, when that function returns it moves on to the next module, etc ... while other thread could be calling on all modules authorization function, etc etc ... when the freeradius thread call a function in the module it will wait for that function to return before moving on to the next module in the radius queue, etc. so using the non blocking pg interface would just introduce whole new sets of problems and will have to use some other mechanism to avoid returning from that function before completing all the work so freeradius can continue to the next module after i finish doing what i have to .... or you have other ideas that would make that easier ? regards!
On 14 June 2011 03:32, [email protected] <[email protected]> wrote: > On 06/13/2011 11:23 PM, Juan Pablo L wrote: >> >> attached is source for database pool module, > > Besides from the locking issues outlined here, you are doing it wrong. > You can run a postgres database connection completely nonblocking, without > threads. > While it is not easy to get things right the first time - better read the > docs twice, it is much easier to use the nonblocking interface than dealing > with threads & mutexes. > > If the database-con is busy, queue the request, if the database-con is > available run a request from the queue, if the database-con wants to read, > EV_READ, if the database-con wants to write, EV_WRITE to the appropriate > callback. > Give each request a callback to report the result, call the callback once > the query is done and block issuing new requests on the database-con during > while the callback is running. > > As there is very little computation required on the client side of a > database connection you do not need threads anyway, and not having mutexes > is likely to make the code easier and more scalable therefore. > > > _______________________________________________ > libev mailing list > [email protected] > http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev > _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
