On Fri, Mar 07, 2014 at 06:54:18AM -0800, Ralph Castain wrote: > >>>>> If you like, I can define the required code in the trunk and let you > >>>>> fill in the event functionality. > >>>> > >>>> That would be great. > >>> > >>> Thanks for your changes. When using --with-ft there are a few compiler > >>> errors which I tried to fix with following patch: > >>> > >>> https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=71521789ef9d248a7eef53030d2ec5de900faa4c > >> > >> That looks okay, with the only caveat being that you wouldn't ordinarily > >> pass the state_caddy_t into a function. It's just there to pass along the > >> job etc in case the callback function needs to reference something. In > >> this case, I can't think of anything the FT event function would need to > >> know - you just want it to quiet all messaging. > > > > I need to pass the type of state to the ft_event() functions: > > > > enum opal_crs_state_type_t { > > OPAL_CRS_NONE = 0, > > OPAL_CRS_CHECKPOINT = 1, > > OPAL_CRS_RESTART_PRE = 2, > > OPAL_CRS_RESTART = 3, /* RESTART_POST */ > > > > so an int is all I need. So I probably need to encode it into *cbdata. Do I > > just use an int directly in *cbdata or should it be part of a struct? > > Why don't you define a job state for each of those, and then you can walk the > state machine thru them if needed? That way the state caddy will already > provide you with the state and you can just pass it to the functions.
Like this? https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=79d6c8262bf809bb2f9ecc853d4a7a42a88654da Adrian
