ClassAdobjects to a Hashtable of
JobQueueJobclass is derived from compat
ClassAd, so it can be passed to any function that wants a
ClassAd; But unlike
ClassAd, it provides a place to hang data members that are useful to the SCHEDD at runtime, but should not be written to the job queue log.
For instance, the autocluster id can now be stored in the job object and never written into the job queue log. In fact, the impetus for this change was the need to have more than a single autocluster set, and thus to have more than one autocluster id associate with each job.
The job queue in the SCHEDD is still an instance of
code has been refactored to be a template class on both the key and the value. The key must have a string representation, but does not have to be a string. And the value must be derived from the compat
For most users of the
, the key still of type
, and the value is of type
just as it was before. But in the SCHEDD. The key is a
, (which is essentially a PROC_ID with methods). The value is class
When external clients of the SCHEDD fetch a
, they still get back a
, but when code internal to the SCHEDD calls
is returned. Not all of these call sites in the SCHEDD have been updated to recognize the change. Some are using a ClassAd* to hold the return value - but many of the key functions have been updated including
It is safe to hold a pointer to a
object in a SCHEDD data structure so long it is removed from that data structure in
, in the destructor of
(which is currently empty), or earlier, if your code can be certain that a job cannot be removed while the code is running.