Re: [Condor-users] Condor and processor affinity

["Ben Burnett" <burnett@xxxxxxxxxxx>]

Hi Matt:

> For condor to do the job objects properly it would have to create a
> separate child process, have that process create the job then that process
> spawn the real child process task. Attaching after the event would be a
> security hole. If the starter is spawned afresh for each task then it
> could do this itself (but it would then be part of the job which might
> make shut down a bit tricky, not to mention it running out of memory!)

I this a security hole in that it might be possible for the child process
to spawn a child process of its own in the time window between the call to
CreateProcess() and AssignProcessToJobObject()?  If so, then I don't think
this affects us, since we start all user processes in a suspended state,
so that we can do a few things of our own, after-which we start the
process.  In our case, there is, effectively, no windows between the call
to CreateProcess() and the one to AssignProcessToJobObject().

My thought, and please correct me if this is a bad approach, was that the
starter would "own" the job object (i.e. keep a copy of it) and only add
the Condor Job's process as a member, and not the starter itself.  This
way the starter could continue to track the Condor job using an extension
to the existing processes tracking framework (i.e. the condor_procd).

> If condor were to do that for us based on MEMORY and a per slot config
> like say SLOT1_AFFINITY_MASK then I'd happily switch off our code.

Would you find having all the Windows Job Object options exposed to be
helpful, or is there a specific subset that, in your experience, has been
used the most.  It seems to me that exposing the quota options would be
helpful, but I'm uncertain about the UI restrictions, for instance.

Regards,
-B