Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] A useful trick with string lists
- Date: Tue, 20 Dec 2016 13:58:03 -0600
- From: Brian Bockelman <bbockelm@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] A useful trick with string lists
> On Dec 20, 2016, at 1:47 PM, Michael Pelletier <Michael.V.Pelletier@xxxxxxxxxxxx> wrote:
>
> Even after a few years of working with HTCondor, Iâm still getting the hang of lists. I just realized something that other folks may find useful, so I thought Iâd send it out.
>
> Iâve been fine-tuning the Grid Engine wrapper I wrote so it can better handle various engineering tools which donât have a native HTCondor or LoadLeveler scheduler interface, and the job-monitoring functionality of these tools is looking for a Grid Engine qstat-format output, which means that JobStatus has to be translated into the appropriate letter code.
>
> What I just realized is that this kind of translation for JobStatus can be done directly in a condor_q âformat by using a string list, along these lines:
>
> condor_q âformat âstate %s\nâ â{ "Undefined", "Idle", "Running", "Removed", "Completed", "Held", "Transferring", "Suspended" }[JobStatus]â
>
> Or for Grid Engine state letter codes:
>
> condor_q âformat âstate %s\nâ â{ "E", "qw", "r", "d", "--", "h", "t", "s" }[JobStatus]â
>
> Youâre declaring a StringList literal and indexing it with the JobStatus attribute of the jobs. Spiffy. I had set up something similar a couple of years ago as a pre-8.4 version of the âqueue fromâ syntax, but I guess I had a failure of imagination when I forgot I could use it in condor_q as well.
>
> Maybe there should be a manual section all about using the List type.
For what it's worth - you don't see a lot of use of Lists within HTCondor itself because the C++ ClassAd list API is a giant pain to use compared to the StringList API (which makes it easy to iterate over strings). The ClassAd list is also fairly memory-inefficient. The ClassAd parser is fairly slow compared to splitting a string into a vector of strings.
Hence, even in new code, a list is more likely to be serialized into a string ("a,b,c"; assumes ',' isn't in the list entry...) than as a ClassAd list {"a", "b", "c"}.
I understand why it is, but it is a bit of a bummer from a ClassAds-the-language perspective.
Brian