On 10/22/2010 01:04 PM, dan clark wrote: > Hi Gentle Readers, > > Is it possible to target the use of cpg_dispatch to only flush outbound > data or only inbound data, but not both simultaneously? For example, in > a single threaded library that would only like to synchronously receive > from corosync, it would be nice to only pull data out of the callbacks > one at a time based on specifically posting buffers. Would adding a > CPG_DISPATCH_SEND and CPG_DISPATCH_RECV be an OK way to provide that > functionality? >
I don't follow your question here. Perhaps an example/use case would help. cpg_dispatch should never be flushing any outbound data (ie data sent from cpg_mcast_joined). To flush one message at a time on inbound messages, you can use CPG_DISPATCH_ONE. > Would it be generally useful to have an interface (for the zero copy > case) that would allow the posting of a iovec to the receive logic to > directly receive into the application buffers? How will the interfaces > change for the proposed 'zero copy' changes? > yes, we have kicked this idea around and that is part of the "topic-zerocopy" line of investigation. We won't get to this line of investigation for some time, if ever, depending on quality of the libqb performance which seems far superior to what we have today in 1.2. > Is the probe of the file descriptor associated with the umbilical cord > between the cpg library and the corosync daemon sufficient to determine > the presence of inbound data available from the library? Based on the yes > use of shared memory for much of the communications between the cpg > library and the daemon is it possible that data is available for > processing yet the file descriptor does not return a positive response > to a probe (via select or epoll) on the file descriptor posted to the yes but the delay is minimal > 'read set' (versus the write or exception set)? Is there a library call > that can be made to definitively determine if there are cpg messages > available to receive into the application from the library (or > conversely, if there are messages pending in the library that have yet > to be flushed to the daemon)? > As IPC works today this is not possible. We are reworking ipc a bit in 2.0 as well, and not sure it will be possible there. Not exactly sure on use case here - could you go into more detail which problem you want to solve? > Is there a description available for the library calls > cpg_iteration_initialize (and friends)? > Long term we plan to deprecate these apis and make that information available via confdb. That is why there is no man pages for them. They will still be available in atleast 2.0 and 3.0. For examples of using the apis for the time being, look at cpgtool. > Thank you for your time! > dan > Do you have performance requirements not met by Corosync flatiron? More details here would help. Regards -steve > > > _______________________________________________ > Openais mailing list > Openais@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
