[Question] future jobid data type and its property

[dongahn]

The resource match module currently assumes the monotonically increasing jobid of int64_t type. For example, the match_request_cb looks like:

static void match_request_cb (flux_t *h, flux_msg_handler_t *w,
                              const flux_msg_t *msg, void *arg)
{

<CUT>

    if (flux_request_unpack (msg, NULL, "{s:s s:I s:s}", "cmd", &cmd,
                             "jobid", &jobid, "jobspec", &js_str) < 0)
        goto error;

Since I am writing a tester to invoke this handler to finish up my current resource module PR, I thought I should ask to minimize future changes.

Will this change in a near future? If so, what will be its data type and property?

[grondo]

@dongahn, see @garlick's PR here flux-framework/flux-core#1626 for the future direction. I think the newly proposed flux_jobid_t is a uint64_t, and could be passed around as an encoded integer or in one of the FLUID string encodings.

The match module should probably not assume monotonically increasing jobids, but the jobids should be loosely ordered. @garlick may have more to add.

[dongahn]

@dongahn, see @garlick's PR here flux-framework/flux-core#1626 for the future direction. I think the newly proposed flux_jobid_t is a uint64_t, and could be passed around as an encoded integer or in one of the FLUID string encodings.

Ah. Thanks. This is great! I can then keep using std::map based on uint64_t or int64_t

The match module should probably not assume monotonically increasing jobids, but the jobids should be loosely ordered. @garlick may have more to add.

In general I think I can easily relax monotonicity assumption. There are some jobid validation checks but this shouldn't be necessary I think. (Need to check the code a bit.)