Yes, I ended up having to get the FD and doing a select on it manually. But to me this makes the blocking read feature of cpg_dispatch useless.
But yes, it does check errno and restart on EINTR: cpg.c:372 <https://github.com/corosync/corosync/blob/e5f2ecab0e6a7d8eabee966a22f03b66e5a612be/lib/cpg.c#L372> cpg_dispatch() calls qb_ipcc_event_recv() ipcc.c:358 <https://github.com/ClusterLabs/libqb/blob/8f90aa6f71c58f887a7cbc1f590e05431ccd79cc/lib/ipcc.c#L358> qb_ipcc_event_recv() calls _check_connection_state_with() ipcc.c:112 <https://github.com/ClusterLabs/libqb/blob/8f90aa6f71c58f887a7cbc1f590e05431ccd79cc/lib/ipcc.c#L112> _check_connection_state_with() calls qb_ipc_us_ready() ipc_setup.c:161 <https://github.com/ClusterLabs/libqb/blob/b4c36efff8b91f287da87590911a01184243cf64/lib/ipc_setup.c#L161> qb_ipc_us_ready() calls poll() ipc_setup.c:163 <https://github.com/ClusterLabs/libqb/blob/b4c36efff8b91f287da87590911a01184243cf64/lib/ipc_setup.c#L163> qb_ipc_us_ready() returns -EAGAIN on EINTR ipcc.c:122 <https://github.com/ClusterLabs/libqb/blob/8f90aa6f71c58f887a7cbc1f590e05431ccd79cc/lib/ipcc.c#L122> _check_connection_state_with() returns the response (-EAGAIN) ipcc.c:361 <https://github.com/ClusterLabs/libqb/blob/8f90aa6f71c58f887a7cbc1f590e05431ccd79cc/lib/ipcc.c#L361> qb_ipcc_event_recv() returns the response(-EAGAIN) cpg.c:377 <https://github.com/corosync/corosync/blob/e5f2ecab0e6a7d8eabee966a22f03b66e5a612be/lib/cpg.c#L377> cpg_dispatch() turns the response (-EAGAIN) into CS_ERR_TRY_AGAIN cpg.c:393 <https://github.com/corosync/corosync/blob/e5f2ecab0e6a7d8eabee966a22f03b66e5a612be/lib/cpg.c#L393> cpg_dispatch() restarts the loop and we go back to cpg.c:372 -Patrick ------------------------------------------------------------------------ *From: *Jan Friesse <[email protected]> *Sent: * 2013-10-23 11:14:28 E *To: *Patrick Hemmer <[email protected]>, [email protected] *Subject: *Re: [corosync] signaling in cpg_dispatch > Patrick, > I'm unsure if I really understand your question. cpg_dispatch doesn't > check errno and doesn't do restart. > > I believe what you want to achieve is alarm handler. Way how to do it, > is to use select/poll on cpg/(any other service) fd and call > cpg_dispatch only when fd is ready for read. Alarm handler can then set > variable which is checked after cpg_dispatch call. If you have only > cpg_dispatch, you even don't need poll, but can directly run endless > loop. so pseudocode fragment: > > int want_exit_loop = 0; > > sigalarm_handler() { > want_exit_loop = 1; > } > > ... > > while (!want_exit_loop) { > cpg_dispatch(); > } > > ... > > If I didn't understood your question correctly, please try reformulate > it or even better, send code fragment. > > Regards, > Honza > > Patrick Hemmer napsal(a): >> So I'm trying to write an application which uses CPG but am having a >> problem with cleanly terminating the application. >> >> The issue is that when calling cpg_dispatch, if the process gets a >> signal while it's sitting on the `poll()` call, and there is a signal >> handler defined, upon return from the signal handler, errno is set to >> EINTR which causes cpg_dispatch to restart the call to qb_ipcc_event_recv. >> Basically nothing other than a SIGKILL (or a signal which has no handler >> and results in the default action of exit) can terminate the app. And >> aside from terminating, if you wanted to use a SIGALRM to break the >> poll() and go do other things, you can't. >> >> I'm using corosync 2.3.2 and libqb 0.14.4 >> >> This assessment correct or am I missing something? >> >> -Patrick >> >> >> >> _______________________________________________ >> discuss mailing list >> [email protected] >> http://lists.corosync.org/mailman/listinfo/discuss >>
_______________________________________________ discuss mailing list [email protected] http://lists.corosync.org/mailman/listinfo/discuss
