GNOME Bugzilla – Bug 651034
Regarding g_cond_wait after g_thread_pool_push in gthreadedresolver
Last modified: 2011-05-31 13:11:33 UTC
Created attachment 188560 [details] [review] g_cond_wait handling in g_thread_pool_push failure patch When i checked the code in gthreadedresolver.c, I observed the below point a) In resolve_sync function, i) We are creating a conditional variable req->cond using g_cond_new. ii) Then, we call g_thread_pool_push. iii) Next we call g_cond_wait on the conditional variable. If the g_thread_pool_push fails due to thread creation failure, we are just simply appending data to the queue of work to do. After the failure, we might wait indefinitely in g_cond_wait. There is not a way where we retry to create the thread and process the queue of work item. In case of g_thread_pool_push failure, we might need to propagate the error so that this function doesn't block forever. To fix this issue we can apply the below patch.
Comment on attachment 188560 [details] [review] g_cond_wait handling in g_thread_pool_push failure patch some style notes (I'll fix these before committing): >Subject: [PATCH] g_cond_wait handling in g_thread_pool_push failure > In resolve_sync function in gthreadedresolver.c, if g_thread_pool_push fails due to thread creation failure, we are just simply appending the data to the queue of work to do. After the failure, we might wait indefinitely in g_cond_wait. > In case of g_thread_pool_push failure, propagate the error so that this function does not blocks forever in case of failure. please line-wrap the commit message >+ g_thread_pool_push (gtr->thread_pool, req, &(req->error)); The other code all uses "&req->error", not "&(req->error)" >+ if(req->error == NULL) likewise, glib style always uses a space between if/for/while and "("