Rongsong Shen
663ea63cc5
Every scheduler (re)join re-pushes the whole config, and both apply paths -- sched_init_resources() (scheduler.c) and core_apply_config_resources() (core_events.c) -- re-added each resource with makeResource(), which refuses an existing name: one ERROR per resource per rejoin (33 in data/xce_scheduler.log), and a genuinely changed definition was dropped just as silently. New libxce resourceApplyDef(): under one write lock, register a new resource (ADDED), or compare an already-registered one on its scheduling-relevant fields -- valtype, ordtype, flags, interval -- and return SAME or CHANGED. Both call sites log SAME at debug, CHANGED as a WARN that the definition is not applied to the running scheduler (updating a registered resource in place would disturb its index and accounting), and only real failures as ERROR. Test test_resource_reapply_same_is_noop_changed_is_reported (EEXIST on an identical re-push before). Scheduler suite 87/87, lib 1/1. Re-verify of data/scheduler-replay-20260925-133708.replay: 0 add-resource ERRORs (33 before), 0 changed-definition WARNs, 0 mismatches, same 60 DISPATCH / 908 PEND decisions. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
21 lines
658 B
C
21 lines
658 B
C
#if !defined(_RESOBH_H_)
|
|
|
|
#define _RESOBJ_H_ 1
|
|
|
|
#include <rtti.h>
|
|
|
|
#include "xce/types.h"
|
|
|
|
extern xce_resource_t* makeResource(var, xce_resource_t*);
|
|
|
|
/* bug-1854: register a pushed resource definition, tolerating re-pushes.
|
|
* Returns RES_APPLY_ADDED (newly registered), RES_APPLY_SAME (already
|
|
* registered with the same scheduling-relevant definition: valtype,
|
|
* ordtype, flags, interval), RES_APPLY_CHANGED (registered with a different
|
|
* definition -- NOT applied; the registered one is kept), or -errno. */
|
|
#define RES_APPLY_ADDED 1
|
|
#define RES_APPLY_SAME 0
|
|
#define RES_APPLY_CHANGED 2
|
|
extern int resourceApplyDef(var, xce_resource_t*);
|
|
|
|
#endif
|