On Tue, Nov 16, 2010 at 04:51:32PM +0900, Keisuke MORI wrote: > 2010/11/14 Lars Ellenberg <[email protected]>: > > On Tue, Nov 09, 2010 at 06:06:30PM +0900, Keisuke MORI wrote: > > >> Ok, then let's just drop the changeset. > >> > >> I agree that srand should not be called many times, > >> but I would rather prefer to just keep the existing behavior > >> since there have been no problems with that so far. > > > > Ok, I'll revert it for now. > > Thanks, I confirmed that the problem went away. > > > > > But I'd rather have it working there. > > Would this patch to the cib do the right thing? > > The patch actually didn't work. I've looked into the code more and now > I realized that the existence of the mainloop is not the issue here; > the g_main_loop_is_running() _always_ fails when NULL is passed. > > glue/lib/clplumbing/cl_random.c: > ---- ---- ---- ---- ---- ---- ---- ---- ---- > static void > get_more_random(void) > { > if (randgen_scheduled || IS_QUEUEFULL) { > return; > } > if (g_main_loop_is_running(NULL)) { > randgen_scheduled = TRUE; > Gmain_timeout_add_full(G_PRIORITY_LOW+1, 10, add_a_random, > NULL, NULL); > } > } > ---- ---- ---- ---- ---- ---- ---- ---- ---- > > > By looking at the source code of glib it looks like this: > http://git.gnome.org/browse/glib/tree/glib/gmain.c#n3157 > ---- ---- ---- ---- ---- ---- ---- ---- ---- > gboolean > g_main_loop_is_running (GMainLoop *loop) > { > g_return_val_if_fail (loop != NULL, FALSE); > g_return_val_if_fail (g_atomic_int_get (&loop->ref_count) > 0, FALSE); > > return loop->is_running; > } > ---- ---- ---- ---- ---- ---- ---- ---- ---- > > I'm wondering the 'get_more_random()' logic had ever worked before.
Probably not. At least it has never been used, according to mercurial. I was the first to use it. > So the proper fix here would be, in my opinion, > just removing the 'get_more_random()' logic in the cluster-glue code. > It does not make sense for me that the g_mainloop is required just for > getting a random value:) I'm fine with that. I'll rip it out then. > The Heartbeat code should still support the current version of > cluster-glue, so I think that the current code in the repository is > just good for the coming 3.0.4. > > > >> Any other backlogs to release the heartbeat packeage? > >> I would look forward to be released it soon! > > > > Me too. Alas ... > > We try to get it out until next Friday (19th November) > > Great! > Thank you for all your effort for the release! For glue, Dejan is working on some memleak bug in lrmd, which is not release critical. And there are a few logd patches pending integration, which are release critical as they fix regressions. Heartbeat proper should be ok, maybe needs some spec file changes? IIRC, someone suggested that libheartbeat should not require heartbeat, because that way, using pacemaker on corosync, you end up having both heartbeat and corosync installed. I'm currently not aware of other issues, so maybe we can even actually get it out this week. I'd like to still run current pacemaker/glue/heartbeat through CTS, unless you have done so already. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
