Jose, I was thinking about that problem a little deeper and what about implementing this: - Store buffer in cpg_inst (so alloc in cpg_initialize, free in cpg_finalize) - When dispatch is called, set variable in cpg_inst (something like is_in_dispatch) before callback and unset it after callback. - IF is_in_dispatch is set, allocate new buffer, else use buffer from cpg_inst Basically, this should solve all problems with (in practice) no perf hit, because 99.9999% code doesn't reenter *_dispatch function, and make rest of 0.0001% code work correctly. Honza Jan Friesse napsal(a): > José Orlando Pereira napsal(a): >> On Thursday 18 April 2013 10:28:49 Jan Friesse wrote: >>> Kernel is magic so almost everything is possible. But to your patch. >>> What about storing dispatch_buf inside cpg_inst? So then, you will >>> allocate dispatch_buf only once in cpg_model_initialize and free it >>> inside cpg_finalize? This should solve your problem + no performance hit >>> possible. >> >> I considered it, but is it clear that *_dispatch(...) functions should not >> ever be reentered? I suppose so, and expect it for cpg as the order of >> callbacks is _very_ relevant, but I'm not sure about the other libs. > > Actually, yes, you are right. *_dispatch can be reentered so we really > need to alloc memory on each call. > > Regards, > Honza > >> >>> Also I really really like your project. Do you have any plans to >>> integrate other libraries as well? Like cmap may be very interesting >>> (ideally something implementing map interface), quorum (there is >>> basically only one callback interesting), ... >> >> No immediate plans, as they do not naturally fit the common JGCS API. >> For instance, the ZooKeeper integration is already quite awkward and >> mostly of academic interest. >> >> But a simple JNI wrapper, closely matching the C API, would indeed be >> interesting and wouldn't take a lot of effort. >> > _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
