yes, i m using mutexes for the timers, so when i modify and reset a timer, the timer is locked and when i try to do something on them from a callback the timer lock is checked from the callback.
Maybe what i m trying to do is estrange but here it goes, i m doing a database pool and the timers are one per database connection, so as to not keep an idle connection connected to the database (to save resources on the database). the timeout is 300 secs to disconnect database connections who have not had any activity in all that time (read from config). So timers are initially set at 300 segs. There is one thread running the ev_run(loop) and there are many other threads dealing with requests to the database, so the flow goes: 1. a database thread requests a db connection to the pool. 2. the pool finds a free connection and locks the connection lock. it does this by trying to find a lock that pthread_mutext_trylock that does not return EBUSY. 3. the pool updates the timer.repeat to 1 hour, does the ev_timer_again and returns the timer to the caller. 4. caller does what it does and then returns the connection to the pool. the caller calls on dbpool_release_connection to do this. 5. the dbpool_release_connection what it does is: the pool updates the timer.repeat to 300 secs, does the ev_timer_again and unlocks the connection lock. 6. the callback that deals with the timer expiration what it does is pthread_mutext_trylock and if it returns EBUSY that means that a connection is holding the database connection and just update timer.repeat for another 1 hour and does ev_timer_again and returns. i m sure the connection does nothing with the timer so it is safe. When pthread_mutext_trylock does not return EBUSY the connection is not taken by anyone and it is disconnected, timer.repeat not updated and ev_timer_again not called. So of course, no connection will hold a connection for 1 hour but it may hold the connection for more than the configured time out (300 secs in the flow above) since it is read from a config file someone may just use 1 secs for the timer timeout so i do not want the callback to be called so many times while it is held by a database thread so that is why i make sure that it will expire 1 hour later while a database thread is holding it. (also i may show a warning message because no way a connection can be held for all that time,something may be defunc). i m testing this by setting to 1 secs in step 3 above and also in step 6 (for the part when pthread_mutex_trylock returns EBUSY) and a message in the timeout callback so i m expecting to see the message (callback being called) every second for as long as the connection is held by the database thread. On 13/06/2011, Brandon Black <[email protected]> wrote: > On Mon, Jun 13, 2011 at 9:38 AM, Juan Pablo L > <[email protected]> wrote: >> yes i m calling ev_timer_again but i m calling from outside the loop >> (not from any callback), i m calling from another thread. >> i m calling ev_break from another thread. > > If you're making calls on a single eventloop from multiple threads, > are you locking for it? This is mentioned in the libev docs. libev > doesn't do locking for you, you have to serialize the calls on a > single loop yourself, e.g. with a pthread mutex. > _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
