If I send 2 messages with CPG_TYPE_AGREED:
node1: cpg_mcast_joined (A)
node1: cpg_mcast_joined (B)
Is there any guarantee that they arrive in the same order (A before B)?
- Dietmar
___
Openais mailing list
Openais@lists.linux-foundation.org
see previous mail on subject
patch included
Index: test/magbench.c
===
--- test/magbench.c (revision 0)
+++ test/magbench.c (revision 0)
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2008, 2009 Red Hat, Inc.
+ *
+ * All rights reserved.
+
On Tue, 2009-04-14 at 12:19 +0200, Dietmar Maurer wrote:
If I send 2 messages with CPG_TYPE_AGREED:
node1: cpg_mcast_joined (A)
node1: cpg_mcast_joined (B)
Is there any guarantee that they arrive in the same order (A before B)?
There is a gaurantee that they arrive in the same order on
Hi guys,
changes compared to take1:
- merge from trunk (logsys_format_set) and fix a mutex deadlock too by
handling error path differently.
- make _logsys_system_setup return int instead of void (make it ready to
return errors)
- drop attribute construct priority in favour of a bit of extra code
On Tue, Apr 14, 2009 at 02:05:10PM +0200, Dietmar Maurer wrote:
So CPG provide a framework to implement distributed finite state
machines (DFSM). But there is no standard way to get the initial state
of the DFSM. Almost all applications need to get the initial state, so I
wonder if it would
From one lone, biased, user's point of view, optimized malloc and memcpy are
uninteresting -- message throughput isn't what I'm looking for. Are there
others out there who see this as important? I *would* be interested in seeing
improvements in the following areas:
. message latency, if that's
On 2009-04-13T16:31:35, Joel Becker joel.bec...@oracle.com wrote:
I think its a great idea.
Ok, all respondents were in favor, so I will submit a miniconf proposal.
We actually have progress, with a lot
of work that we talked about in Prague starting to see the light of day
in
When a new node joins, CPG immediately change mode to
DFSM_MODE_SYNC. Then all members send their state.
When a node received the states of all members, it computes the
new
state by merging all received states (dfsm_state_merge_fn), and
finally switches mode to
Yes. I'm not sure if a generic service for this would be used
much
or
not...
maybe.
Btw, how large is an average checkpoint in dlm? Just wonder how much
data needs to be transferred.
I've never measured, but it's a trivially small amount of data.
Around
32
bytes of data per
On Tue, 2009-04-14 at 14:05 +0200, Dietmar Maurer wrote:
So CPG provide a framework to implement distributed finite state
machines (DFSM). But there is no standard way to get the initial state
of the DFSM. Almost all applications need to get the initial state, so I
wonder if it would make
On Tue, 2009-04-14 at 11:12 -0500, David Teigland wrote:
From one lone, biased, user's point of view, optimized malloc and memcpy are
uninteresting -- message throughput isn't what I'm looking for. Are there
others out there who see this as important? I *would* be interested in seeing
On Tue, Apr 14, 2009 at 01:18:14PM -0700, Steven Dake wrote:
. message latency, if that's even possible
Reducing the time a token is held reduces latency. So memcpy and malloc
specials does reduce latency. I don't have measures of how much,
however.
That would be interesting to measure
You might try taking a look at exec/sync.c
it is a synchronization engine. Basically it takes configuration
changes into account to call sync_init, sync_process, sync_abort, or
sync_activate. These 4 states then activate the new dato a model.
This
could easily be done as an addon api
Cool idea if it wasn't totally integrated with CPG but instead some
external service which people could use in addition to CPG.
Thats the plan.
My current problem is the state merge function. There should be a
standard way to merge state (when the user does not want to provide his
own merge
14 matches
Mail list logo
